From harald@alvestrand.no Fri Jun 1 00:37:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73CD21F8628 for ; Fri, 1 Jun 2012 00:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 0h8UJmTlm+qg for ; Fri, 1 Jun 2012 00:37:32 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 83EC121F8435 for ; Fri, 1 Jun 2012 00:37:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 582D439E106; Fri, 1 Jun 2012 09:37:31 +0200 (CEST) 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 lM+C+UYfdOjZ; Fri, 1 Jun 2012 09:37:29 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EB7A839E091; Fri, 1 Jun 2012 09:37:28 +0200 (CEST) Message-ID: <4FC87136.6020606@alvestrand.no> Date: Fri, 01 Jun 2012 09:37:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jim Barnett References: <4FC5E024.1010206@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C160388E9@inba-mail01.sonusnet.com> <4FC71D7A.9040601@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Regarding the use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 07:37:33 -0000 I'm starting to think that we need to encapsulate the identity work somehow. It's clear that there needs to be a basic set of tools exposed from the lower layer RTCWEB work (chiefly DTLS, and possibly EKT) to support identity assertions about communications partners. But it's clear that our current use cases document doesn't adequately cover requirements on what kind of identity can exist, and what information they need to be able to verify about each other - and that's a rather big undertaking to get right. draft-ietf-rtcweb-identity-use-cases, anyone? Harald On 05/31/2012 03:04 PM, Jim Barnett wrote: > Yes, let's set aside some time to discuss this at the interim. When I brought up call center use cases a while ago, we reached the conclusion that the webRTC endpoint was the corporate gateway/ACD and that anything behind it (including the agent) was out of scope (which is another way of saying that it could work any way the corporation wanted.) The result was that call centers fell under legacy inter-op and no changes were needed to the use cases. > > In general corporate/call center uses of webRTC will be important, so it's worth going over this once more to make sure we agree on how they fit into the framework. > > - Jim > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK > Sent: Thursday, May 31, 2012 3:28 AM > To: Ravindran, Parthasarathi > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Regarding the use-case document > > On 05/30/2012 11:31 AM, Ravindran, Parthasarathi wrote: >> Stefan, >> >> >> 1) I have mentioned in Call Center [2] usecase calls for "Anonymous" >> identity for agents >> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295.html) >> and also Andrew Hutton mentioned the same in the another mail >> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html) >> >> 2) Also in another mail thread, "Anonymous" identity for customer is >> discussed as part of >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04254.html >> >> In case any more information required for clarity, please let me know. >> Also, I'm fine with discussion about these usecase in interim meeting. > Hi Partha, > > I would prefer if we discussed this at the interim before adding. The main reason is that the use-case document, and requirements, currently focus on media and data streams. When doing the first draft we deliberately left things like identity handling, find-and-connect and so on out of scope. > > This was partly inspired by the charter (that talks about enabling innovation on top of a set of basic components - those being peer-to-peer audio, video and data) and partly from that there are already a lot of web services used every day which has solved this - they have implemented presence, text chat, messaging, ... already and in theory it would be simple to add video etc. if we just got those "basic components" in place. > > If the use-case document is to be updated to cover things like identity, user management and so on that would be a big change, and I would prefer that to be discussed before starting actual work. > > Br, > Stefan > >> Thanks Partha >> >>> -----Original Message----- From: rtcweb-bounces@ietf.org >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK >>> Sent: Wednesday, May 30, 2012 2:24 PM To: rtcweb@ietf.org Subject: >>> [rtcweb] Regarding the use-case document >>> >>> The rtcweb chairs asked for input on the use-case document on April >>> 27th [1]. >>> >>> Browsing the emails that followed, I note: >>> >>> 1. Proposal for a call center use case (made by Jim Barnett) [2] >>> >>> 2. Proposal to add peer-to-peer file sharing to the simple video comm >>> service (made by Tim Terriberri) [3] >>> >>> 3. Comments related to security, SRTP and key exchange, F20 (by Dan >>> Wing) [4] >>> >>> 4. Request for clarifying "eavesdropping", Andrew Hutton [5] >>> >>> 5. Enterprise policies use-cases proposed, Roman Shpount [6] >>> >>> 6. Multiparty with low complex central node, Stefan Håkansson [7] >>> >>> 7. Multiparty with central node that can not decipher media Oscar >>> Ohlsson [8] >>> >>> 8. Four new reqs proposed (to be mapped to either new or existing >>> use- cases), one additional use-case proposed, by Cullen Jennings >>> [9]. Reqs: 8a. Req: When A calls B, B does not reveal their IP >>> address to A 8b. Req: B can tell that the encrypted media is from A >>> and not from a MITM 8c. Req: Be able to switch off Voice activity >>> detection (if present) 8d. Req: Be able to prioritize between streams >>> New use-case: "Collaboration between companies with node [in media >>> path] that does/can not decipher media" >>> >>> 9. Proposal from Magnus Westerlund to clarify the language a bit [10] >>> regarding 4. in this list >>> >>> Is anything important missing from the list above? >>> >>> Going through this list (and the discussion that followed on each >>> item) it seems quite clear that: >>> >>> A. The language should be clarified (as Magnus proposed [10]), e.g. >>> to clarify that also the data channel should be encrypted (this >>> relates to 3. and 9. in the previous list) >>> >>> B. One more derivative of the "Simple Video Communication Service" >>> use-case should be added to add peer-to-peer file sharing (this >>> proposal got some support, no objection, and was also mentioned many >>> times during the MV interim) >>> >>> C. There is no need to clarify "eavesdropping" (item 4. in the >>> previous list); EKR proposed to do that as part of the security >>> document instead >>> >>> D. For the new requirements proposed by Cullen (8a - d in the >>> previous list), 8a and 8b can be incorporated in existing use cases, >>> 8c is already covered in the "Distributed Music Band" >>> use-case, 8d can be added to the "Hockey Game Viewer" use case. >>> Regarding 8d it can be noted that there is already a requirement on >>> "being able to use priority functions in network nodes" (F24); 8d >>> would be different and relate more to how the browser reduces send >>> rate for different flows as a response to e.g. network congestion. >>> The reqs seem uncontroversial to me. >>> >>> Unless there are objections to this, the editors plan to update the >>> document according to A - D above. >>> >>> >>> >>> It is less clear on what to do regarding the call-center use case >>> [2], the enterprise policies use-cases [6] and the two use-cases >>> where a central node (in the media path) must not be able to access >>> deciphered media [8] and [9]; I think this should be discussed at the >>> interim meeting. >>> >>> Comments? >>> >>> Stefan >>> >>> [1] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html >>> [2] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html >>> [3] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html >>> [4] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html >>> [5] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html >>> [6] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html >>> [7] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html >>> [8] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html >>> [9] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html >>> [10] >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html >>> _______________________________________________ rtcweb mailing list >>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From goran.ap.eriksson@ericsson.com Fri Jun 1 00:42:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6BB21F8619 for ; Fri, 1 Jun 2012 00:42:19 -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 W46lTwCU+yoS for ; Fri, 1 Jun 2012 00:42:18 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 02D0021F846F for ; Fri, 1 Jun 2012 00:42:17 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-12-4fc87258f3e9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C5.DB.11869.85278CF4; Fri, 1 Jun 2012 09:42:17 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.214]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 1 Jun 2012 09:42:17 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Harald Alvestrand , Jim Barnett Date: Fri, 1 Jun 2012 09:42:15 +0200 Thread-Topic: [rtcweb] Regarding the use-case document Thread-Index: Ac0/yWqMUXL03OkgTsKlOaWy4hxMngAADIQw Message-ID: References: <4FC5E024.1010206@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C160388E9@inba-mail01.sonusnet.com> <4FC71D7A.9040601@ericsson.com> <4FC87136.6020606@alvestrand.no> In-Reply-To: <4FC87136.6020606@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW5k0Ql/g86l3BbH+rrYLJquTmOx WPuvnd2B2ePKhCusHkvfdrB5LFnykymAOYrLJiU1J7MstUjfLoEr48PuC0wFfzwrrtz9xdbA 2GTTxcjJISFgIrH8x1JmCFtM4sK99WxdjFwcQgKnGCV2Pb/HAuEsYJSY/eoBK0gVm4C3xLQV Z4FsDg4RgQiJaS1lIGFmAXWJO4vPsYPYLAIqEvvP3mECsYUFTCUmPv8O1ioiYCYxt387O4Rt JPFqUwNYDa9AuMSR+7cZIXb9ZZR4+6UXrIFTQFei6c92RhCbUUBW4v53kINAlolL3Hoynwni agGJJXvOQ30gKvHy8T9WiHoZiVOL/rNC1OtJ3Jg6hQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk 7CwkLbOQtMxC0rKAkWUVo3BuYmZOermRXmpRZnJxcX6eXnHqJkZgRB3c8lt1B+OdcyKHGKU5 WJTEea237vEXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLht9dI9+j3T4haqTpdIdng9zy3Q 6Vbqd58Al6nf4v5P9nNIuNbsFGCfUWC3vLbP/YEmh/gyfrbVvI+3N3o3qyaY2rSq6Bxrv9nZ 2SpxqrTnydwFuhkJM5/PSOTbKtpjeFOx9/iDP1uaU+w0tqU7nJ387PGRnhO/bO4FHvd3ySpt eWLSIMhwRomlOCPRUIu5qDgRAC1MQdB2AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding the use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 07:42:19 -0000 =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: den 1 juni 2012 09:37 > To: Jim Barnett > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Regarding the use-case document >=20 > I'm starting to think that we need to encapsulate the=20 > identity work somehow. >=20 > It's clear that there needs to be a basic set of tools=20 > exposed from the lower layer RTCWEB work (chiefly DTLS, and=20 > possibly EKT) to support identity assertions about=20 > communications partners. >=20 > But it's clear that our current use cases document doesn't=20 > adequately cover requirements on what kind of identity can=20 > exist, and what information they need to be able to verify=20 > about each other - and that's a rather big undertaking to get right. >=20 > draft-ietf-rtcweb-identity-use-cases, anyone? This could easily become a Pandoras box, right? We need the hooks, but at t= he same time not solve the whole identity area. Do You have any idea as to how to limit the scope of this? A proposal that = we can discuss in the interim meeting could perhaps be useful. >=20 > Harald >=20 > On 05/31/2012 03:04 PM, Jim Barnett wrote: > > Yes, let's set aside some time to discuss this at the=20 > interim. When I brought up call center use cases a while=20 > ago, we reached the conclusion that the webRTC endpoint was=20 > the corporate gateway/ACD and that anything behind it=20 > (including the agent) was out of scope (which is another way=20 > of saying that it could work any way the corporation wanted.)=20 > The result was that call centers fell under legacy inter-op=20 > and no changes were needed to the use cases. > > > > In general corporate/call center uses of webRTC will be=20 > important, so it's worth going over this once more to make=20 > sure we agree on how they fit into the framework. > > > > - Jim > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > > Behalf Of Stefan Hakansson LK > > Sent: Thursday, May 31, 2012 3:28 AM > > To: Ravindran, Parthasarathi > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Regarding the use-case document > > > > On 05/30/2012 11:31 AM, Ravindran, Parthasarathi wrote: > >> Stefan, > >> > >> > >> 1) I have mentioned in Call Center [2] usecase calls for=20 > "Anonymous" > >> identity for agents > >> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295.html) > >> and also Andrew Hutton mentioned the same in the another mail > >> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html) > >> > >> 2) Also in another mail thread, "Anonymous" identity for=20 > customer is=20 > >> discussed as part of=20 > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04254.html > >> > >> In case any more information required for clarity, please=20 > let me know. > >> Also, I'm fine with discussion about these usecase in=20 > interim meeting. > > Hi Partha, > > > > I would prefer if we discussed this at the interim before=20 > adding. The main reason is that the use-case document, and=20 > requirements, currently focus on media and data streams. When=20 > doing the first draft we deliberately left things like=20 > identity handling, find-and-connect and so on out of scope. > > > > This was partly inspired by the charter (that talks about=20 > enabling innovation on top of a set of basic components -=20 > those being peer-to-peer audio, video and data) and partly=20 > from that there are already a lot of web services used every=20 > day which has solved this - they have implemented presence,=20 > text chat, messaging, ... already and in theory it would be=20 > simple to add video etc. if we just got those "basic=20 > components" in place. > > > > If the use-case document is to be updated to cover things=20 > like identity, user management and so on that would be a big=20 > change, and I would prefer that to be discussed before=20 > starting actual work. > > > > Br, > > Stefan > > > >> Thanks Partha > >> > >>> -----Original Message----- From: rtcweb-bounces@ietf.org=20 > >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK > >>> Sent: Wednesday, May 30, 2012 2:24 PM To: rtcweb@ietf.org Subject: > >>> [rtcweb] Regarding the use-case document > >>> > >>> The rtcweb chairs asked for input on the use-case=20 > document on April=20 > >>> 27th [1]. > >>> > >>> Browsing the emails that followed, I note: > >>> > >>> 1. Proposal for a call center use case (made by Jim Barnett) [2] > >>> > >>> 2. Proposal to add peer-to-peer file sharing to the simple video=20 > >>> comm service (made by Tim Terriberri) [3] > >>> > >>> 3. Comments related to security, SRTP and key exchange,=20 > F20 (by Dan > >>> Wing) [4] > >>> > >>> 4. Request for clarifying "eavesdropping", Andrew Hutton [5] > >>> > >>> 5. Enterprise policies use-cases proposed, Roman Shpount [6] > >>> > >>> 6. Multiparty with low complex central node, Stefan H=E5kansson [7] > >>> > >>> 7. Multiparty with central node that can not decipher media Oscar=20 > >>> Ohlsson [8] > >>> > >>> 8. Four new reqs proposed (to be mapped to either new or existing > >>> use- cases), one additional use-case proposed, by Cullen Jennings=20 > >>> [9]. Reqs: 8a. Req: When A calls B, B does not reveal their IP=20 > >>> address to A 8b. Req: B can tell that the encrypted media=20 > is from A=20 > >>> and not from a MITM 8c. Req: Be able to switch off Voice activity=20 > >>> detection (if present) 8d. Req: Be able to prioritize between=20 > >>> streams New use-case: "Collaboration between companies=20 > with node [in=20 > >>> media path] that does/can not decipher media" > >>> > >>> 9. Proposal from Magnus Westerlund to clarify the language a bit=20 > >>> [10] regarding 4. in this list > >>> > >>> Is anything important missing from the list above? > >>> > >>> Going through this list (and the discussion that followed on each > >>> item) it seems quite clear that: > >>> > >>> A. The language should be clarified (as Magnus proposed=20 > [10]), e.g. > >>> to clarify that also the data channel should be encrypted (this=20 > >>> relates to 3. and 9. in the previous list) > >>> > >>> B. One more derivative of the "Simple Video Communication Service" > >>> use-case should be added to add peer-to-peer file sharing (this=20 > >>> proposal got some support, no objection, and was also=20 > mentioned many=20 > >>> times during the MV interim) > >>> > >>> C. There is no need to clarify "eavesdropping" (item 4. in the=20 > >>> previous list); EKR proposed to do that as part of the security=20 > >>> document instead > >>> > >>> D. For the new requirements proposed by Cullen (8a - d in the=20 > >>> previous list), 8a and 8b can be incorporated in existing=20 > use cases,=20 > >>> 8c is already covered in the "Distributed Music Band" > >>> use-case, 8d can be added to the "Hockey Game Viewer" use case. > >>> Regarding 8d it can be noted that there is already a=20 > requirement on=20 > >>> "being able to use priority functions in network nodes" (F24); 8d=20 > >>> would be different and relate more to how the browser=20 > reduces send=20 > >>> rate for different flows as a response to e.g. network congestion. > >>> The reqs seem uncontroversial to me. > >>> > >>> Unless there are objections to this, the editors plan to=20 > update the=20 > >>> document according to A - D above. > >>> > >>> > >>> > >>> It is less clear on what to do regarding the call-center use case=20 > >>> [2], the enterprise policies use-cases [6] and the two use-cases=20 > >>> where a central node (in the media path) must not be able=20 > to access=20 > >>> deciphered media [8] and [9]; I think this should be discussed at=20 > >>> the interim meeting. > >>> > >>> Comments? > >>> > >>> Stefan > >>> > >>> [1] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html > >>> [2] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html > >>> [3] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html > >>> [4] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html > >>> [5] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html > >>> [6] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html > >>> [7] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html > >>> [8] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html > >>> [9] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html > >>> [10] > >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html > >>> _______________________________________________ rtcweb=20 > mailing list=20 > >>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From pravindran@sonusnet.com Fri Jun 1 01:52:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C033F21F861C for ; Fri, 1 Jun 2012 01:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk+qEU8FPFqR for ; Fri, 1 Jun 2012 01:52:06 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id DD3F521F85C5 for ; Fri, 1 Jun 2012 01:52:05 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT8iCtf76Bzp9vx6DSgAjHWlxEYIQqE+O@postini.com; Fri, 01 Jun 2012 01:52:05 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 1 Jun 2012 04:52:31 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 1 Jun 2012 14:22:00 +0530 From: "Ravindran, Parthasarathi" To: Harald Alvestrand , Jim Barnett Thread-Topic: [rtcweb] Regarding the use-case document Thread-Index: AQHNPkHH1GnjCWGVq0iTWXWu67SC5ZbiCn9AgAEakwCAAF38gIABNwIAgABrlSA= Date: Fri, 1 Jun 2012 08:51:59 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1603985C@inba-mail01.sonusnet.com> References: <4FC5E024.1010206@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C160388E9@inba-mail01.sonusnet.com> <4FC71D7A.9040601@ericsson.com> <4FC87136.6020606@alvestrand.no> In-Reply-To: <4FC87136.6020606@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding the use-case document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 08:52:08 -0000 Harald, Thanks for providing support for adding identity related usecases. As Stefa= n mentioned in the below mail, the authors deliberately excluded identity u= secases initially. The single RTCWeb usecase document will give better pict= ure over multiple usecase document as the solution of RTCWeb identity, secu= rity, media has the linkage. I'll wait for usecase document Editors opinion= and interim discussion here. Having said that in case it is decided not to add RTCWeb identity usecases = within the current RTCWeb usecases document as it is big change, it will be= better to work for draft-ietf-rtcweb-identity-use-cases and I volunteer to= be one of the document reviewer & provide inputs. Thanks Partha >-----Original Message----- >From: Harald Alvestrand [mailto:harald@alvestrand.no] >Sent: Friday, June 01, 2012 1:07 PM >To: Jim Barnett >Cc: Stefan Hakansson LK; Ravindran, Parthasarathi; rtcweb@ietf.org >Subject: Re: [rtcweb] Regarding the use-case document > >I'm starting to think that we need to encapsulate the identity work >somehow. > >It's clear that there needs to be a basic set of tools exposed from the >lower layer RTCWEB work (chiefly DTLS, and possibly EKT) to support >identity assertions about communications partners. > >But it's clear that our current use cases document doesn't adequately >cover requirements on what kind of identity can exist, and what >information they need to be able to verify about each other - and that's >a rather big undertaking to get right. > >draft-ietf-rtcweb-identity-use-cases, anyone? > > Harald > >On 05/31/2012 03:04 PM, Jim Barnett wrote: >> Yes, let's set aside some time to discuss this at the interim. When I >brought up call center use cases a while ago, we reached the conclusion >that the webRTC endpoint was the corporate gateway/ACD and that anything >behind it (including the agent) was out of scope (which is another way >of saying that it could work any way the corporation wanted.) The >result was that call centers fell under legacy inter-op and no changes >were needed to the use cases. >> >> In general corporate/call center uses of webRTC will be important, so >it's worth going over this once more to make sure we agree on how they >fit into the framework. >> >> - Jim >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Stefan Hakansson LK >> Sent: Thursday, May 31, 2012 3:28 AM >> To: Ravindran, Parthasarathi >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Regarding the use-case document >> >> On 05/30/2012 11:31 AM, Ravindran, Parthasarathi wrote: >>> Stefan, >>> >>> >>> 1) I have mentioned in Call Center [2] usecase calls for "Anonymous" >>> identity for agents >>> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295.html) >>> and also Andrew Hutton mentioned the same in the another mail >>> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html) >>> >>> 2) Also in another mail thread, "Anonymous" identity for customer is >>> discussed as part of >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04254.html >>> >>> In case any more information required for clarity, please let me >know. >>> Also, I'm fine with discussion about these usecase in interim >meeting. >> Hi Partha, >> >> I would prefer if we discussed this at the interim before adding. The >main reason is that the use-case document, and requirements, currently >focus on media and data streams. When doing the first draft we >deliberately left things like identity handling, find-and-connect and so >on out of scope. >> >> This was partly inspired by the charter (that talks about enabling >innovation on top of a set of basic components - those being peer-to- >peer audio, video and data) and partly from that there are already a lot >of web services used every day which has solved this - they have >implemented presence, text chat, messaging, ... already and in theory it >would be simple to add video etc. if we just got those "basic >components" in place. >> >> If the use-case document is to be updated to cover things like >identity, user management and so on that would be a big change, and I >would prefer that to be discussed before starting actual work. >> >> Br, >> Stefan >> >>> Thanks Partha >>> >>>> -----Original Message----- From: rtcweb-bounces@ietf.org >>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK >>>> Sent: Wednesday, May 30, 2012 2:24 PM To: rtcweb@ietf.org Subject: >>>> [rtcweb] Regarding the use-case document >>>> >>>> The rtcweb chairs asked for input on the use-case document on April >>>> 27th [1]. >>>> >>>> Browsing the emails that followed, I note: >>>> >>>> 1. Proposal for a call center use case (made by Jim Barnett) [2] >>>> >>>> 2. Proposal to add peer-to-peer file sharing to the simple video >>>> comm service (made by Tim Terriberri) [3] >>>> >>>> 3. Comments related to security, SRTP and key exchange, F20 (by Dan >>>> Wing) [4] >>>> >>>> 4. Request for clarifying "eavesdropping", Andrew Hutton [5] >>>> >>>> 5. Enterprise policies use-cases proposed, Roman Shpount [6] >>>> >>>> 6. Multiparty with low complex central node, Stefan H=E5kansson [7] >>>> >>>> 7. Multiparty with central node that can not decipher media Oscar >>>> Ohlsson [8] >>>> >>>> 8. Four new reqs proposed (to be mapped to either new or existing >>>> use- cases), one additional use-case proposed, by Cullen Jennings >>>> [9]. Reqs: 8a. Req: When A calls B, B does not reveal their IP >>>> address to A 8b. Req: B can tell that the encrypted media is from A >>>> and not from a MITM 8c. Req: Be able to switch off Voice activity >>>> detection (if present) 8d. Req: Be able to prioritize between >>>> streams New use-case: "Collaboration between companies with node [in >>>> media path] that does/can not decipher media" >>>> >>>> 9. Proposal from Magnus Westerlund to clarify the language a bit >>>> [10] regarding 4. in this list >>>> >>>> Is anything important missing from the list above? >>>> >>>> Going through this list (and the discussion that followed on each >>>> item) it seems quite clear that: >>>> >>>> A. The language should be clarified (as Magnus proposed [10]), e.g. >>>> to clarify that also the data channel should be encrypted (this >>>> relates to 3. and 9. in the previous list) >>>> >>>> B. One more derivative of the "Simple Video Communication Service" >>>> use-case should be added to add peer-to-peer file sharing (this >>>> proposal got some support, no objection, and was also mentioned many >>>> times during the MV interim) >>>> >>>> C. There is no need to clarify "eavesdropping" (item 4. in the >>>> previous list); EKR proposed to do that as part of the security >>>> document instead >>>> >>>> D. For the new requirements proposed by Cullen (8a - d in the >>>> previous list), 8a and 8b can be incorporated in existing use cases, >>>> 8c is already covered in the "Distributed Music Band" >>>> use-case, 8d can be added to the "Hockey Game Viewer" use case. >>>> Regarding 8d it can be noted that there is already a requirement on >>>> "being able to use priority functions in network nodes" (F24); 8d >>>> would be different and relate more to how the browser reduces send >>>> rate for different flows as a response to e.g. network congestion. >>>> The reqs seem uncontroversial to me. >>>> >>>> Unless there are objections to this, the editors plan to update the >>>> document according to A - D above. >>>> >>>> >>>> >>>> It is less clear on what to do regarding the call-center use case >>>> [2], the enterprise policies use-cases [6] and the two use-cases >>>> where a central node (in the media path) must not be able to access >>>> deciphered media [8] and [9]; I think this should be discussed at >>>> the interim meeting. >>>> >>>> Comments? >>>> >>>> Stefan >>>> >>>> [1] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html >>>> [2] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html >>>> [3] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html >>>> [4] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html >>>> [5] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html >>>> [6] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html >>>> [7] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html >>>> [8] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html >>>> [9] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html >>>> [10] >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html >>>> _______________________________________________ rtcweb mailing list >>>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> From fluffy@iii.ca Fri Jun 1 09:39:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3D411E80B4 for ; Fri, 1 Jun 2012 09:39:44 -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 lli0JPLPc0Xw for ; Fri, 1 Jun 2012 09:39:43 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 88ACB11E8074 for ; Fri, 1 Jun 2012 09:39:43 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DF90422E25C; Fri, 1 Jun 2012 12:39:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 1 Jun 2012 10:39:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:39:44 -0000 I'm interested in this use case.=20 It seems like if the the use of the work happening in = public-webcrypto@w3.org to access things like SIM cards, combined with = the Identity Proxy work here, might be able to solve a use case like = this without any private information leaving the SIIM card. I've got no = concrete idea on how to do this but seems like it might be possible... Cullen On May 29, 2012, at 11:02 AM, Cameron Byrne wrote: > Is there yet a pointer on how a SIM / IMS based identity will work > with the webRTC web server for authentication? >=20 > I think the obvious approach is for the SIM secret key to be bound to > a username / password on the web server, and the web server proxies > the authentication and registration into IMS (if you give me the right > username credentials via the web, i will register you into IMS with > the secret key), but that requires the undesirable step of exposing > the SIM secret key to the web server or someplace outside the HSS/HLR > for binding with the username password. >=20 > Thoughts? Pointers? >=20 > Thanks, >=20 > CB > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From rbarnes@bbn.com Fri Jun 1 10:40:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9321F8A57 for ; Fri, 1 Jun 2012 10:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruJhrKPrGLHL for ; Fri, 1 Jun 2012 10:40:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AAC0821F8A58 for ; Fri, 1 Jun 2012 10:40:44 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:55066) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SaVpa-000Nsi-1A; Fri, 01 Jun 2012 13:40:10 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 1 Jun 2012 13:40:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93331CDC-BC36-4B64-B403-1D61FD0BC4A6@bbn.com> References: To: Cullen Jennings X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] authenticating against IMS HSS/HLR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 17:40:45 -0000 +1=20 WebCrypto is accepting use cases now, and this would be a good one. --Richard On Jun 1, 2012, at 12:39 PM, Cullen Jennings wrote: >=20 > I'm interested in this use case.=20 >=20 > It seems like if the the use of the work happening in = public-webcrypto@w3.org to access things like SIM cards, combined with = the Identity Proxy work here, might be able to solve a use case like = this without any private information leaving the SIIM card. I've got no = concrete idea on how to do this but seems like it might be possible... >=20 > Cullen >=20 >=20 > On May 29, 2012, at 11:02 AM, Cameron Byrne wrote: >=20 >> Is there yet a pointer on how a SIM / IMS based identity will work >> with the webRTC web server for authentication? >>=20 >> I think the obvious approach is for the SIM secret key to be bound to >> a username / password on the web server, and the web server proxies >> the authentication and registration into IMS (if you give me the = right >> username credentials via the web, i will register you into IMS with >> the secret key), but that requires the undesirable step of exposing >> the SIM secret key to the web server or someplace outside the HSS/HLR >> for binding with the username password. >>=20 >> Thoughts? Pointers? >>=20 >> Thanks, >>=20 >> CB >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Cary.Bran@plantronics.com Fri Jun 1 16:00:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D992B11E808D for ; Fri, 1 Jun 2012 16:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_VISITOURSITE=2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k51q+tQ2-pki for ; Fri, 1 Jun 2012 16:00:32 -0700 (PDT) Received: from mail3.plantronics.com (mail3.plantronics.com [12.151.41.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF9011E809A for ; Fri, 1 Jun 2012 16:00:32 -0700 (PDT) Received: from usscch03.plt.plantronics.com (usscch03.plt.plantronics.com [10.1.3.26]) by mail3.plantronics.com (8.13.8/8.13.8) with ESMTP id q51N0VLD018466 for ; Fri, 1 Jun 2012 16:00:31 -0700 Received: from USSCMB03.plt.plantronics.com ([fe80::5824:67c8:930e:7c1e]) by USSCCH03.plt.plantronics.com ([::1]) with mapi id 14.02.0247.003; Fri, 1 Jun 2012 16:00:31 -0700 From: "Bran, Cary" To: "rtcweb@ietf.org" Thread-Topic: Focused Review of RTP usage draft Thread-Index: AQHNQEpYrkK7WtwpfUK3E3ynkElrnw== Date: Fri, 1 Jun 2012 23:00:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.1.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <06938099BD01FC4C8256C3AF74CB088F@plantronics.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.63.1.49 Subject: [rtcweb] Focused Review of RTP usage draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 23:00:34 -0000 Hello RTC-Web WG, Below are some comments/feedback that Charles Eckel and I had from our focused review of the WebRTC RTP usage draft - http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-02 Regards, Cary and Charles Overall feedback: The draft covers some very important topics and is very thorough and well written. A theme throughout the draft is supporting legacy devices. From our read we were unsure what position this draft is is with regards to interworking with legacy devices/systems, sections 3.1 (translator), 4.2, 4.5 do not seem to readily support interworking, while section 4.4 does. We would ask the authors to please clarify their position. Section: Abstract Please consider revising the first sentence of the abstract and first sentence of paragraph two of the introduction as it is a little unclear to the reader. A possible suggestion for revision would be (take it or leave it): The Web Real-Time Communication (WebRTC) framework provides support for native interactive voice and video communications between web browsers. Section: 2 For the terminology section - why not just adopt the usual RFC 2119 language? Assuming the decision moving forward is to define new terms, please note the following comment. Currently RECOMMENDED is defined as, "Should be included as its brings significant benefit, but the solution can potentially work without it." This definition is too vague. A suggested rewording is, RECOMMENDED: "Should be included as it brings significant benefit; however, the solution can work without it, though potentially in a more limited manner." Section: 3.1 Supported RTP Topologies Overall: To educate the reader with some of the issues with the proposed topologies, it may be worthwhile (but maybe not possible in ASCII art) to show the number of sessions instead of a bidirectional <----> notation. For example in Figure 4: RTP Translator (Relay) with Only Unicast Paths I my mental model of the topology was this (I removed the "D" endpoint for clarity). +---+ +---+ | |----> +------------+ <----| | | A | <-C--| | --A->| B | +---+ <-B--| | --C->+---+ | Translator | +---+----> | | | |<-B-- | | | C |<-A-- | | +---+ +------------+ Multi-unicast: It may be worth expanding this topology to include scenarios in which it is not a full mesh, such as a sender sending to a subset of 2 or more receivers, or a few senders sending to the complete set of receivers. The basic idea being that you may have some participants that are receive only, or send only. An example scenario could be using a recording service to record a Google hangout session. Mixer: Another downside is that there is a typically a loss of information (e.g. the loss of video or a participant that is not speaking, or a loss of audio of speaker not selected as an active speaker) Transport Translator: Where the draft reads, "It simply forwards the media from all other to all the other", it should instead read, "It simply forwards the media from each endpoint to all other endpoints."The scalability and bandwidth concerns are similar to the multi-unicast topology, with merely the distribution burden shifted to a centralized node. Near the end of the section, it reads, "The intention is that the presence of the translator is transparent to A, however it is not certain that is possible." This is a good goal. Hopefully subsequent versions of this draft can expand on it. The very last sentence of the this section may want to be reworded, a suggestion here would be: "The scenario above is included as a reference and discussion point for future mechanisms using a Translator to support legacy end-points interoperating within a WebRTC environment." Section: 3.2 Perhaps add a reference to section 5 here? Section: 4.3 Choice of RTP Payload Formats This section is not clear, particularly the exception related to multiplexing. One thing that needs to be kept in mind, and perhaps should be stated explicitly, is the handling outlined in RFC 3264: 7. Offerer Processing of the Answer When the offerer receives the answer, it MAY send media on the accepted stream(s) (assuming it is listed as sendrecv or recvonly in the answer). It MUST send using a media format listed in the answer, and it SHOULD use the first media format listed in the answer when it does send. : : The offerer MAY immediately cease listening for media formats that were listed in the initial offer, but not present in the answer. Section: 5 Overall feedback. This is a great section and very informative. As I understand RTP, both sides have to implement the extensions in order for the extensions to be used. This currently this section is not requiring any of the extensions to be implemented, my question to the authors is what is the future purpose for this section? Are some of these extensions going to become mandatory in a future revision of the draft? Section: 5.2 Header Extensions The last two paragraphs of this section include introductory text for sections 5.2.1-5.2.3. The information contained within these paragraphs is redundant to and could fall out of sync with sections 5.2.1-5.2.3. We would recommend that the authors chop out introductory text to avoid duplication and potential contradictions in future revisions of the draft. Section: 6.1 Retransmission Expand the last paragraph to include avoiding overly aggressive retransmission schemes at the expense of being a bad internet citizen. Section: 6.2.3 Recommendations for FEC The recommendation for FEC is not clearly stated in this section. It would be valuable to the reader to have a recommendation based upon results from experiments/analysis of FIR/PLI vs. retransmission/FEC, plus some guidance as to when either rmethod is appropriate. Section: 7.2 Some expansion for the reader is needed here. A big help would be to clarify the problem via example and then to propose (if there is) a solution to the problem. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, p= lease DO NOT disclose the contents to another person, store or copy the inf= ormation in any medium, or use any of the information contained in or attac= hed to this transmission for any purpose. If you have received this transmi= ssion in error, please immediately notify the sender by reply email or at p= rivacy@plantronics.com, and destroy the original transmission and its attac= hments without reading or saving in any manner. For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com. From richard.ejzak@alcatel-lucent.com Sun Jun 3 16:09:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4777921F8610 for ; Sun, 3 Jun 2012 16:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUnhpWpPlxD7 for ; Sun, 3 Jun 2012 16:09:56 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8221F858F for ; Sun, 3 Jun 2012 16:09: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 q53N9sHM014167 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 4 Jun 2012 01:09:54 +0200 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Jun 2012 01:09:54 +0200 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Sun, 3 Jun 2012 19:09:52 -0400 From: "Ejzak, Richard P (Richard)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: Ac1B3fo89iycBsSlSNO3kxpjdRSOag== Date: Sun, 3 Jun 2012 23:09:51 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92FC303US70UWXCHMBA05zamal_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 23:09:58 -0000 --_000_03FBA798AC24E3498B74F47FD082A92FC303US70UWXCHMBA05zamal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. I am sen= ding this notice to rtcweb since this is the group that triggered recent wo= rk on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. It = might be useful to discuss the ideas in the ID before avtcore meets in Vanc= ouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard) Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration. There are sup= erficial similarities with an expired draft from last year in http://tools.= ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a differ= ent take on the use of SSRC as the basis for multi session multiplexing tha= t I think is superior and worthy of consideration as a potential replacemen= t for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. The IETF Secretariat --_000_03FBA798AC24E3498B74F47FD082A92FC303US70UWXCHMBA05zamal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see the mail attached below that I just sent to a= vtcore announcing a personal ID I just submitted on the topic of media mult= iplexing.  I am sending this notice to rtcweb since this is the group that triggered recent work on RTP= multiplexing.

 

I also request the rtcweb chairs consider giving me some= time to present this work at next week’s interim meeting if there is= time on the agenda.  It might be useful to discuss the ideas in the ID before avtcore meets in Vancouver.

 

Richard

 

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: 'avt@ietf.org'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt=

 

http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.tx= t

 

In response to the chairs' request for additional input on the mult= i session issue, I have submitted this draft for your consideration.  = There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-ros= enberg-rtcweb-rtpmux-00.txt, but my draft has a different take on the use o= f SSRC as the basis for multi session multiplexing that I think is superior= and worthy of consideration as a potential replacement for BUNDLE and/or SHIM.  Please comment.=

 

Richard

 

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

From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

Sent: Sunday, June 03, 2012 5:16 PM

To: Ejzak, Richard P (Richard)

Subject: New Version Notification for draft-ejzak-avtcore-rtp-subse= ssions-00.txt

 

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt ha= s been successfully submitted by Richard Ejzak and posted to the IETF repos= itory.

 

Filename:   draft-ejzak-avtcore-rtp-subsessions

Revision:   00

Title:          &= nbsp; Media multiplexing with Real-time Transport Protocol (RTP) subsession= s

Creation date:    2012-06-04

WG ID:          &= nbsp; Individual Submission

Number of pages: 9

 

Abstract:

   This document describes a means of multiplexing RTP st= reams having

   different media types within a single transport connec= tion and how to

   represent this multiplexing option in SDP.  This = mechanism is an

   alternative to the BUNDLE and SHIM proposals currently= under active

   consideration in AVTCORE.  Instead of adding an e= xtra multiplexing

   header as in SHIM to allow multiple RTP sessions withi= n a single

   transport connection, or using the payload type field = to separate

   different media streams within a single RTP session, t= his document

   describes how to partition the existing SSRC space to = create RTP

   subsessions from a single RTP session.  A filter = can be used to

   identify each RTP subsession for different QoS handlin= g as necessary.

   RTP subsessions can be treated like RTP sessions with = a few

   restrictions.  In particular, SSRC mapping may be= needed when

   forwarding RTP streams into an RTP subsession to avoid= SSRC

   conflicts, but there are few use cases in which this l= imitation is a

   concern and RTP subsessions can be disabled if necessa= ry.

 

           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       

 

 

The IETF Secretariat

 

 

 

--_000_03FBA798AC24E3498B74F47FD082A92FC303US70UWXCHMBA05zamal_-- From christer.holmberg@ericsson.com Mon Jun 4 00:22:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72911E8081 for ; Mon, 4 Jun 2012 00:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 OP-bCj6JTAnb for ; Mon, 4 Jun 2012 00:22:38 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C36F511E8079 for ; Mon, 4 Jun 2012 00:22:37 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-95-4fcc623cc369 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2D.A6.00702.C326CCF4; Mon, 4 Jun 2012 09:22:36 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 4 Jun 2012 09:22:34 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" Date: Mon, 4 Jun 2012 09:22:34 +0200 Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: Ac1B3fo89iycBsSlSNO3kxpjdRSOagAQuY+w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DD@ESESSCMS0356.eemea.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.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_7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DDESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvra5N0hl/g9u71Sx6G8It1v5rZ3dg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGXMPX2AvuNfMWNE58zBrA+Ot4i5GTg4JAROJ ly9eMULYYhIX7q1n62Lk4hASOMUocXFTMytIQkhgAaPErw9OXYwcHGwCFhLd/7RBwiICWRJf P09hBrFZBFQkVqxZyApSIizgLrHwvDREiYfEjy1z2CFsI4mnNzawgdi8AuESO/uWs0BMj5A4 PuUQmM0pEClx98h9sHMYgc75fmoNE4jNLCAucevJfCaIMwUkluw5zwxhi0q8fPyPFaJeVOJO +3pGiPp8iZ+TH7NA7BKUODnzCcsERpFZSEbNQlI2C0kZRFxP4sbUKWwQtrbEsoWvmSFsXYkZ /w6xIIsvYGRfxSicm5iZk15urpdalJlcXJyfp1ecuokRGE8Ht/w22MG46b7YIUZpDhYlcV49 1f3+QgLpiSWp2ampBalF8UWlOanFhxiZODilGhg93l7qUnL6u8/tZL4my2UuzmI7ltVNMlYK u2faqcX+4nRkexL4gtl0Te3Hgo5+lvla34xiNi1ePtO5w0LlkuUsxdL8/rk+RZ4sdhu4/NIa GARK9l7g7zx0uXx9Hm+Tl0vdkSXd73W5hA/NW/Ln+uNJtzqvFaiZrNO+Oflu24zpXzQO5bm7 fVNiKc5INNRiLipOBABgIl/gdQIAAA== Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 07:22:41 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DDESESSCMS0356e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Richard, I will not comment on the RTP aspects of your proposal, but I don't underst= and your comments regarding BUNDLE. The core purpose of BUNDLE is to allow the usage of identical IP address:po= rt information for multiple m- lines. It is true that BUNDLE defines that, by default, all media belong to the sa= me RTP session. But, nothing prevents you from using BUNDLE also with multi= ple RTP sessions, RTP "subsession" etc. You simply need an extension mechan= ism to indicate/negotiate such usage (in your case the ssrc-prefix could p= erhaps be used for that). Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ejzak, Richard P (Richard) Sent: 4. kes=E4kuuta 2012 2:10 To: rtcweb@ietf.org Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. I am sen= ding this notice to rtcweb since this is the group that triggered recent wo= rk on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. It = might be useful to discuss the ideas in the ID before avtcore meets in Vanc= ouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard) Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration. There are sup= erficial similarities with an expired draft from last year in http://tools.= ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a differ= ent take on the use of SSRC as the basis for multi session multiplexing tha= t I think is superior and worthy of consideration as a potential replacemen= t for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. The IETF Secretariat --_000_7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DDESESSCMS0356e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Richard,

 

I will not co= mment on the RTP aspects of your proposal, but I don’t understand you= r comments regarding BUNDLE.

 

The core purpose of BUNDLE is to allow the usage o= f identical IP address:port information for multiple m- lines.

 

It is true that = BUNDLE defines that, by default, all media belong to the same RTP session. = But, nothing prevents you from using BUNDLE also with multiple RTP sessions= , RTP “subsession” etc. You simply need an extension mechanism = =A0to indicate/negotiate such usage (in your case the ssrc-prefix could per= haps be used for that).

 

Regards,

 

Christer

&nbs= p;

From: rtcweb-bounces@ie= tf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ejzak, Richard = P (Richard)
Sent: 4. kes=E4kuuta 2012 2:10
To: rtcweb@i= etf.org
Subject: [rtcweb] draft on media multiplexing submitted t= o AVTCORE

 =

Please see the mail attached below that I just sent t= o avtcore announcing a personal ID I just submitted on the topic of media m= ultiplexing.  I am sending this notice to rtcweb since this is the gro= up that triggered recent work on RTP multiplexing.

 

I also request the rtcweb = chairs consider giving me some time to present this work at next week’= ;s interim meeting if there is time on the agenda.  It might be useful= to discuss the ideas in the ID before avtcore meets in Vancouver.

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Richard

 

-----Original Message-----
From: Ejzak, Richard P (Richard)
= Sent: Sunday, June 03, 2012 6:08 PM
To: 'avt@ietf.org'
Subject: [AVTC= ORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

 

ht= tp://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt

 

In response to the chairs' request for additional input on the multi sessi= on issue, I have submitted this draft for your consideration.  There a= re superficial similarities with an expired draft from last year in http://t= ools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has= a different take on the use of SSRC as the basis for multi session multipl= exing that I think is superior and worthy of consideration as a potential r= eplacement for BUNDLE and/or SHIM.  Please comment.

 

Richard

 

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

From= : internet-drafts@ietf.org = [mailto:internet-draft= s@ietf.org]

Sent: Sunday, June 0= 3, 2012 5:16 PM

To: Ejzak, Richard P = (Richard)

Subject: New Version Notifi= cation for draft-ejzak-avtcore-rtp-subsessions-00.txt

 

A new version= of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been successfully s= ubmitted by Richard Ejzak and posted to the IETF repository.

=

 

Filena= me:   draft-ejzak-avtcore-rtp-subsessions

Revision:   00

Title:           = ; Media multiplexing with Real-time Transport Protocol (RTP) subsessions

Creation date:    2012-0= 6-04

WG ID:    &n= bsp;       Individual Submission

Number of pages: 9

 

Abstract:

   This document describes a means of m= ultiplexing RTP streams having

 =   different media types within a single transport connection and how t= o

   represent this multipl= exing option in SDP.  This mechanism is an

   alternative to the BUNDLE and SHIM proposals curren= tly under active

   conside= ration in AVTCORE.  Instead of adding an extra multiplexing=

   header as in SHIM to allow multipl= e RTP sessions within a single

 =   transport connection, or using the payload type field to separate

   different media streams wi= thin a single RTP session, this document

   describes how to partition the existing SSRC space to crea= te RTP

   subsessions from = a single RTP session.  A filter can be used to

   identify each RTP subsession for different QoS= handling as necessary.

   = RTP subsessions can be treated like RTP sessions with a few

<= p class=3DMsoPlainText>   restrictions.  In particular, SSRC= mapping may be needed when

 &nb= sp; forwarding RTP streams into an RTP subsession to avoid SSRC<= /p>

   conflicts, but there are few use ca= ses in which this limitation is a

&nb= sp;  concern and RTP subsessions can be disabled if necessary.

 

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

 

 

The IETF Secretariat

 =

 

 =

= --_000_7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DDESESSCMS0356e_-- From richard.ejzak@alcatel-lucent.com Mon Jun 4 06:34:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7284321F87E9 for ; Mon, 4 Jun 2012 06:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.184 X-Spam-Level: X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW2j8fVUseWx for ; Mon, 4 Jun 2012 06:34:18 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id C4BD921F87E7 for ; Mon, 4 Jun 2012 06:34:17 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q54DU0J8027472 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Jun 2012 15:34:13 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Jun 2012 15:33:47 +0200 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 4 Jun 2012 09:33:45 -0400 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: Ac1B3fo89iycBsSlSNO3kxpjdRSOagAQuY+wAAyIPyA= Date: Mon, 4 Jun 2012 13:33:45 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92FC38D@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DD@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DD@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92FC38DUS70UWXCHMBA05zamal_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:34:21 -0000 --_000_03FBA798AC24E3498B74F47FD082A92FC38DUS70UWXCHMBA05zamal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christer, I agree that BUNDLE in its current form would be consistent with the RTP su= bsessions proposal, but it would also be technically redundant. I'm not su= re exactly which comments in the paper you object to. I agree with you abo= ut the purpose of BUNDLE and that it works (with limitations) for its inten= ded purpose. My understanding is that BUNDLE is primarily intended for the= case where a single RTP session is shared across m lines. There is no nee= d for BUNDLE (and specifically the constrained PT assignment) when you use = another mechanism such as SHIM or RTP subsessions to segregate the flows as= sociated with each m line. Whether the grouping framework is applicable is= open for discussion. So perhaps we should separately discuss the grouping framework and constrai= ned PT assignment procedures associated with BUNDLE to be sure we understan= d one another. The source of our disagreement may be more what is meant by= "BUNDLE" than anything else. I have no problem redefining it if there is = agreement to do so! I look forward to an in-depth discussion of these issues in Stockholm. BR, Richard ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 04, 2012 2:23 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi Richard, I will not comment on the RTP aspects of your proposal, but I don't underst= and your comments regarding BUNDLE. The core purpose of BUNDLE is to allow the usage of identical IP address:po= rt information for multiple m- lines. It is true that BUNDLE defines that, by default, all media belong to the sa= me RTP session. But, nothing prevents you from using BUNDLE also with multi= ple RTP sessions, RTP "subsession" etc. You simply need an extension mechan= ism to indicate/negotiate such usage (in your case the ssrc-prefix could p= erhaps be used for that). Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ejzak, Richard P (Richard) Sent: 4. kes=E4kuuta 2012 2:10 To: rtcweb@ietf.org Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. I am sen= ding this notice to rtcweb since this is the group that triggered recent wo= rk on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. It = might be useful to discuss the ideas in the ID before avtcore meets in Vanc= ouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard) Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration. There are sup= erficial similarities with an expired draft from last year in http://tools.= ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a differ= ent take on the use of SSRC as the basis for multi session multiplexing tha= t I think is superior and worthy of consideration as a potential replacemen= t for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. The IETF Secretariat --_000_03FBA798AC24E3498B74F47FD082A92FC38DUS70UWXCHMBA05zamal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Christer,<= /p>

I agree that BUNDLE in its current for= m would be consistent with the RTP subsessions proposal, but it would also = be technically redundant.  I’m not sure exactly which comments in the paper you object to= .  I agree with you about the purpose of BUNDLE and that it works (wit= h limitations) for its intended purpose.  My understanding is that BUN= DLE is primarily intended for the case where a single RTP session is shared across m lines.  There is no need for BUNDLE (a= nd specifically the constrained PT assignment) when you use another mechani= sm such as SHIM or RTP subsessions to segregate the flows associated with e= ach m line.  Whether the grouping framework is applicable is open for discussion.

 

So perhaps we should separately discus= s the grouping framework and constrained PT assignment procedures associate= d with BUNDLE to be sure we understand one another.  The source of our disagreement may b= e more what is meant by “BUNDLE” than anything else.  I ha= ve no problem redefining it if there is agreement to do so!

 

I look forward to an in-depth discussi= on of these issues in Stockholm.

 

BR, Richard

 

From: Chri= ster Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, June 04, 2012 = 2:23 AM
To: Ejzak, Richard P (Richar= d); rtcweb@ietf.org
Subject: RE: [rtcweb] draft = on media multiplexing submitted to AVTCORE

 

= Hi Richa= rd,

= &nb= sp;

= I will n= ot comment on the RTP aspects of your proposal, but I don’t understan= d your comments regarding BUNDLE.

= &nb= sp;

= The core= purpose of BUNDLE is to allow the usage of identical IP address:port infor= mation for multiple m- lines.

= &nb= sp;

= It is tr= ue that BUNDLE defines that, by default, all media belong to the same RTP s= ession. But, nothing prevents you from using BUNDLE also with multiple RTP sessions, RTP “subsession” etc. = You simply need an extension mechanism  to indicate/negotiate such usa= ge (in your case the ssrc-prefix could perhaps be used for that).

= &nb= sp;

= Regards,=

= &nb= sp;

= Christer=

= &nb= sp;

From: rtcw= eb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ejzak, Richard = P (Richard)
Sent: 4. kes=E4kuuta 2012 2:= 10
To: rtcweb@ietf.org
Subject: [rtcweb] draft on m= edia multiplexing submitted to AVTCORE

 

Please see the mail attached below that I just sent to a= vtcore announcing a personal ID I just submitted on the topic of media mult= iplexing.  I am sending this notice to rtcweb since this is the group that triggered recent work on RTP= multiplexing.

 

I also request the rtcweb chairs consider giving me some= time to present this work at next week’s interim meeting if there is= time on the agenda.  It might be useful to discuss the ideas in the ID before avtcore meets in Vancouver.<= /font>

 

Richard

 

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: 'avt@ietf.org'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt=

 

http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.tx= t

 

In response to the chairs' request for additional input on the mult= i session issue, I have submitted this draft for your consideration.  = There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my d= raft has a different take on the use of SSRC as the basis for multi session= multiplexing that I think is superior and worthy of consideration as a pot= ential replacement for BUNDLE and/or SHIM.  Please comment.

 

Richard

 

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

From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

Sent: Sunday, June 03, 2012 5:16 PM

To: Ejzak, Richard P (Richard)

Subject: New Version Notification for draft-ejzak-avtcore-rtp-subse= ssions-00.txt

 

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt ha= s been successfully submitted by Richard Ejzak and posted to the IETF repos= itory.

 

Filename:   draft-ejzak-avtcore-rtp-subsessions

Revision:   00

Title:          &= nbsp; Media multiplexing with Real-time Transport Protocol (RTP) subsession= s

Creation date:    2012-06-04

WG ID:          &= nbsp; Individual Submission

Number of pages: 9

 

Abstract:

   This document describes a means of multiplexing RTP st= reams having

   different media types within a single transport connec= tion and how to

   represent this multiplexing option in SDP.  This = mechanism is an

   alternative to the BUNDLE and SHIM proposals currently= under active

   consideration in AVTCORE.  Instead of adding an e= xtra multiplexing

   header as in SHIM to allow multiple RTP sessions withi= n a single

   transport connection, or using the payload type field = to separate

   different media streams within a single RTP session, t= his document

   describes how to partition the existing SSRC space to = create RTP

   subsessions from a single RTP session.  A filter = can be used to

   identify each RTP subsession for different QoS handlin= g as necessary.

   RTP subsessions can be treated like RTP sessions with = a few

   restrictions.  In particular, SSRC mapping may be= needed when

   forwarding RTP streams into an RTP subsession to avoid= SSRC

   conflicts, but there are few use cases in which this l= imitation is a

   concern and RTP subsessions can be disabled if necessa= ry.

 

           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       

 

 

The IETF Secretariat

 

 

 

--_000_03FBA798AC24E3498B74F47FD082A92FC38DUS70UWXCHMBA05zamal_-- From christer.holmberg@ericsson.com Mon Jun 4 06:54:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670FA21F85EA for ; Mon, 4 Jun 2012 06:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 IKvb7kDjzTLt for ; Mon, 4 Jun 2012 06:54:03 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 23B6B21F8698 for ; Mon, 4 Jun 2012 06:54:02 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-01-4fccbdf9e4d3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A2.10.00702.9FDBCCF4; Mon, 4 Jun 2012 15:54:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 4 Jun 2012 15:54:01 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" Date: Mon, 4 Jun 2012 15:54:00 +0200 Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: Ac1B3fo89iycBsSlSNO3kxpjdRSOagAQuY+wAAyIPyAAAVD9EA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C45A1C70C@ESESSCMS0356.eemea.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DD@ESESSCMS0356.eemea.ericsson.se> <03FBA798AC24E3498B74F47FD082A92FC38D@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC38D@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre6vvWf8DRr6GS16G8It1v5rZ3dg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGffPn2Ar+G5QsffvY7YGxgMaXYycHBICJhKP 1y9mgbDFJC7cW8/WxcjFISRwilFi7p3/zCAJIYEFjBLnz0R3MXJwsAlYSHT/0wYJiwhkSXz9 PAWshEVAReJ92xtGkBJhAXeJheelIUo8JH5smcMOYTtJzJi4G6ycVyBc4tKT5SwQ078ySrw4 rA5icwpESszrmcAEYjMCnfP91Bowm1lAXOLWk/lMEGcKSCzZc54ZwhaVePn4HytEvajEnfb1 jBD1ehI3pk5hg7C1JZYtfA21V1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxSicm5iZk15u rpdalJlcXJyfp1ecuokRGB0Ht/w22MG46b7YIUZpDhYlcV491f3+QgLpiSWp2ampBalF8UWl OanFhxiZODilGhgjRBuchftNir/s2v1MX2WXUT+nqGD9t/7cshe2r89NYv/sWuwrPiHaqFrn /3fxxav3pm5OzeX5tJLzY3i68Yrd82N631YqyNbG2fQ3ab5Ib/35wfSzkF3n16hOk61TVtkW Hdxlr74962CHQV5LtNxphYP7L3gtm7+JZ9qHc6fXSprvET/d8F6JpTgj0VCLuag4EQAaapzc XAIAAA== Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:54:04 -0000 Hi, > I agree that BUNDLE in its current form would be consistent with the RTP = subsessions proposal, but it would also be technically redundant. =A0I'm no= t sure exactly which comments in the paper you object to. =A0I agree with y= ou about the purpose of BUNDLE=20 > and that it works (with limitations) for its intended purpose. =A0My unde= rstanding is that BUNDLE is primarily intended for the case where a single = RTP session is shared across m lines. That is not true. That is only the "default" that we chose, and the limitat= ions in the draft are related to the case when you use a single RTP session= - they are not related to the BUNDLE mechanism as such. >=A0There is no need for BUNDLE (and specifically the constrained PT assign= ment) when you use another mechanism such as SHIM or RTP subsessions to seg= regate the=20 > flows associated with each m line. =A0Whether the grouping framework is a= pplicable is open for discussion. You still need something in order to use identical IP address:port values f= or multiple m- lines. > So perhaps we should separately discuss the grouping framework and constr= ained PT assignment procedures associated with BUNDLE to be sure we underst= and one another.=A0 > The source of our disagreement may be more what is meant by "BUNDLE" than= anything else. =A0I have no problem redefining it if there is agreement to= do so! We should separate the discussions on how the multiplexing is done on the R= TP level (which I think your draft mostly focuses on) and how it is signale= d in SDP. Regards, Christer ________________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 04, 2012 2:23 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi Richard, I will not comment on the RTP aspects of your proposal, but I don't underst= and your comments regarding BUNDLE. The core purpose of BUNDLE is to allow the usage of identical IP address:po= rt information for multiple m- lines. It is true that BUNDLE defines that, by default, all media belong to the sa= me RTP session. But, nothing prevents you from using BUNDLE also with multi= ple RTP sessions, RTP "subsession" etc. You simply need an extension mechan= ism =A0to indicate/negotiate such usage (in your case the ssrc-prefix could= perhaps be used for that). Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ejzak, Richard P (Richard) Sent: 4. kes=E4kuuta 2012 2:10 To: rtcweb@ietf.org Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. =A0I am s= ending this notice to rtcweb since this is the group that triggered recent = work on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. =A0I= t might be useful to discuss the ideas in the ID before avtcore meets in Va= ncouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard)=20 Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration.=A0 There are s= uperficial similarities with an expired draft from last year in http://tool= s.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a diff= erent take on the use of SSRC as the basis for multi session multiplexing t= hat I think is superior and worthy of consideration as a potential replacem= ent for BUNDLE and/or SHIM.=A0 Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename:=A0=A0 draft-ejzak-avtcore-rtp-subsessions Revision:=A0=A0 00 Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Media multiplexing with Real-time T= ransport Protocol (RTP) subsessions Creation date:=A0=A0=A0 2012-06-04 WG ID:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Individual Submission Number of pages: 9 Abstract: =A0=A0 This document describes a means of multiplexing RTP streams having =A0=A0 different media types within a single transport connection and how t= o =A0=A0 represent this multiplexing option in SDP.=A0 This mechanism is an =A0=A0 alternative to the BUNDLE and SHIM proposals currently under active =A0=A0 consideration in AVTCORE.=A0 Instead of adding an extra multiplexing =A0=A0 header as in SHIM to allow multiple RTP sessions within a single =A0=A0 transport connection, or using the payload type field to separate =A0=A0 different media streams within a single RTP session, this document =A0=A0 describes how to partition the existing SSRC space to create RTP =A0=A0 subsessions from a single RTP session.=A0 A filter can be used to =A0=A0 identify each RTP subsession for different QoS handling as necessary= . =A0=A0 RTP subsessions can be treated like RTP sessions with a few =A0=A0 restrictions.=A0 In particular, SSRC mapping may be needed when =A0=A0 forwarding RTP streams into an RTP subsession to avoid SSRC =A0=A0 conflicts, but there are few use cases in which this limitation is a =A0=A0 concern and RTP subsessions can be disabled if necessary. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=20 The IETF Secretariat =A0 From richard.ejzak@alcatel-lucent.com Mon Jun 4 07:55:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F80B21F85DD for ; Mon, 4 Jun 2012 07:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.206 X-Spam-Level: X-Spam-Status: No, score=-10.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 R6WOhuDk6yaO for ; Mon, 4 Jun 2012 07:55:06 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 22F0021F85D9 for ; Mon, 4 Jun 2012 07:55:05 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q54Errx8027316 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Jun 2012 16:55:03 +0200 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, 4 Jun 2012 16:54:59 +0200 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 4 Jun 2012 10:54:56 -0400 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: AQHNQlmHr4sXpNLTDEum7ofZ5Z2iR5bqMXsA Date: Mon, 4 Jun 2012 14:54:55 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92FC3C8@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DD@ESESSCMS0356.eemea.ericsson.se> <03FBA798AC24E3498B74F47FD082A92FC38D@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C70C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C45A1C70C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:55:07 -0000 Hi Christer, I agree with you that we should separate the discussion of how multiplexing= is done at the RTP level from how it is signaled in SDP. My draft address= es both aspects by describing how to partition the SSRC space between m lin= es at the RTP level and how to signal that use in SDP using a new "ssrc-pre= fix" attribute. With the use of the ssrc-prefix attribute to identify RTP subsessions it is= not absolutely necessary to use the grouping framework to indicate bundlin= g, since the ssrc-prefix attribute implicitly indicates the bundling. Thes= e two mechanisms are compatible but redundant. BR, Richard=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 04, 2012 8:54 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi, > I agree that BUNDLE in its current form would be consistent with the RTP = subsessions proposal, but it would also be technically redundant. =A0I'm no= t sure exactly which comments in the paper you object to. =A0I agree with y= ou about the purpose of BUNDLE=20 > and that it works (with limitations) for its intended purpose. =A0My unde= rstanding is that BUNDLE is primarily intended for the case where a single = RTP session is shared across m lines. That is not true. That is only the "default" that we chose, and the limitat= ions in the draft are related to the case when you use a single RTP session= - they are not related to the BUNDLE mechanism as such. >=A0There is no need for BUNDLE (and specifically the constrained PT assign= ment) when you use another mechanism such as SHIM or RTP subsessions to seg= regate the=20 > flows associated with each m line. =A0Whether the grouping framework is a= pplicable is open for discussion. You still need something in order to use identical IP address:port values f= or multiple m- lines. > So perhaps we should separately discuss the grouping framework and constr= ained PT assignment procedures associated with BUNDLE to be sure we underst= and one another.=A0 > The source of our disagreement may be more what is meant by "BUNDLE" than= anything else. =A0I have no problem redefining it if there is agreement to= do so! We should separate the discussions on how the multiplexing is done on the R= TP level (which I think your draft mostly focuses on) and how it is signale= d in SDP. Regards, Christer ________________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 04, 2012 2:23 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi Richard, I will not comment on the RTP aspects of your proposal, but I don't underst= and your comments regarding BUNDLE. The core purpose of BUNDLE is to allow the usage of identical IP address:po= rt information for multiple m- lines. It is true that BUNDLE defines that, by default, all media belong to the sa= me RTP session. But, nothing prevents you from using BUNDLE also with multi= ple RTP sessions, RTP "subsession" etc. You simply need an extension mechan= ism =A0to indicate/negotiate such usage (in your case the ssrc-prefix could= perhaps be used for that). Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ejzak, Richard P (Richard) Sent: 4. kes=E4kuuta 2012 2:10 To: rtcweb@ietf.org Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. =A0I am s= ending this notice to rtcweb since this is the group that triggered recent = work on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. =A0I= t might be useful to discuss the ideas in the ID before avtcore meets in Va= ncouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard)=20 Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration.=A0 There are s= uperficial similarities with an expired draft from last year in http://tool= s.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a diff= erent take on the use of SSRC as the basis for multi session multiplexing t= hat I think is superior and worthy of consideration as a potential replacem= ent for BUNDLE and/or SHIM.=A0 Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename:=A0=A0 draft-ejzak-avtcore-rtp-subsessions Revision:=A0=A0 00 Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Media multiplexing with Real-time T= ransport Protocol (RTP) subsessions Creation date:=A0=A0=A0 2012-06-04 WG ID:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Individual Submission Number of pages: 9 Abstract: =A0=A0 This document describes a means of multiplexing RTP streams having =A0=A0 different media types within a single transport connection and how t= o =A0=A0 represent this multiplexing option in SDP.=A0 This mechanism is an =A0=A0 alternative to the BUNDLE and SHIM proposals currently under active =A0=A0 consideration in AVTCORE.=A0 Instead of adding an extra multiplexing =A0=A0 header as in SHIM to allow multiple RTP sessions within a single =A0=A0 transport connection, or using the payload type field to separate =A0=A0 different media streams within a single RTP session, this document =A0=A0 describes how to partition the existing SSRC space to create RTP =A0=A0 subsessions from a single RTP session.=A0 A filter can be used to =A0=A0 identify each RTP subsession for different QoS handling as necessary= . =A0=A0 RTP subsessions can be treated like RTP sessions with a few =A0=A0 restrictions.=A0 In particular, SSRC mapping may be needed when =A0=A0 forwarding RTP streams into an RTP subsession to avoid SSRC =A0=A0 conflicts, but there are few use cases in which this limitation is a =A0=A0 concern and RTP subsessions can be disabled if necessary. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=20 The IETF Secretariat =A0 From internet-drafts@ietf.org Mon Jun 4 08:42:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4210221F88C8; Mon, 4 Jun 2012 08:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Z0vvumJMwxtn; Mon, 4 Jun 2012 08:42:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C99321F88C0; Mon, 4 Jun 2012 08:42: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.02 Message-ID: <20120604154239.14951.40382.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2012 08:42:39 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 15:42:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Web Real-Time Communication Use-cases and Requirements Author(s) : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-08.txt Pages : 27 Date : 2012-06-04 This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream and data exchange services provided by the browser. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-require= ments-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirem= ents-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requiremen= ts/ From christer.holmberg@ericsson.com Mon Jun 4 09:10:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B8E21F85D1 for ; Mon, 4 Jun 2012 09:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 IembAcOpTYe0 for ; Mon, 4 Jun 2012 09:10:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EBAEF21F846A for ; Mon, 4 Jun 2012 09:10:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-a2-4fccdddab060 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8F.4F.28636.ADDDCCF4; Mon, 4 Jun 2012 18:10:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 4 Jun 2012 18:10:02 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" Date: Mon, 4 Jun 2012 18:10:02 +0200 Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: AQHNQlmHr4sXpNLTDEum7ofZ5Z2iR5bqMXsAgAAgkZI= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C457B13C0@ESESSCMS0356.eemea.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DD@ESESSCMS0356.eemea.ericsson.se> <03FBA798AC24E3498B74F47FD082A92FC38D@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C70C@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92FC3C8@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC3C8@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre6tu2f8Da5vsrDobQi3WPuvnd2B yaP12V5WjyVLfjIFMEVx2aSk5mSWpRbp2yVwZXR13mAseG9RcWTRbeYGxtu6XYycHBICJhK/ 1nxigrDFJC7cW8/WxcjFISRwilFixsbJ7BDOAkaJKT9vsXYxcnCwCVhIdP/TBmkQEciS+Pp5 CjOIzSKgIrH34jVGkBJhAXeJheelIUo8JH5smcMOYVtJtF/+wQJSwisQLjGnWQRi+gRmiYvH doHVcApESlzY+xlsJCPQPd9PrQG7jVlAXOLWk/lQdwpILNlznhnCFpV4+fgfK0S9qMSd9vWM EPV6EjemTmGDsLUlli18DVbPKyAocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIUzk3MzEkv N9RLLcpMLi7Oz9MrTt3ECIyPg1t+6+5gPHVO5BCjNAeLkjgvV9J+fyGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2M9oud1NlNHtfJJyUmPIhdcmBF6KO3BjV5GQ/u7vom9LwtbUfrntcL/n70 jvgmvOn5vJUywWkp/iUH7c7bxsaGFi6ZGeH+7cEP32aGxv6PzZs4X96PPGf/XzVxz5I0yx0f Dqdvtu6dz2XcpV1tlx2ezGfH9P1k5JO6Xk7XTJ95W4Uzv+xrPFCpxFKckWioxVxUnAgAxKJZ z10CAAA= Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:10:05 -0000 Hi Richard, > I agree with you that we should separate the discussion of how multiplexi= ng is done at the RTP level from=20 > how it is signaled in SDP. My draft addresses both aspects by describing= how to partition the SSRC space=20 > between m lines at the RTP level and how to signal that use in SDP using = a new "ssrc-prefix" attribute. Sure. But as far as the IP address:port re-use is concerned, I think you sh= ould use BUNDLE. > With the use of the ssrc-prefix attribute to identify RTP subsessions it = is not absolutely necessary to use the=20 > grouping framework to indicate bundling, since the ssrc-prefix attribute = implicitly indicates the bundling. =20 > These two mechanisms are compatible but redundant. I see no reason for having two mechanisms to do the same thing, and in gene= ral I also think we should try to avoid implicit indications. If often caus= es troubles later on. Using BUNDLE would also make it easier to define fallback behavior. For exa= mple, you could say that if the SDP answerer does not support the ssrc-pref= ix, but it does support BUNDLE, the fallback would be default BUNDLE behavi= or. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 04, 2012 8:54 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi, > I agree that BUNDLE in its current form would be consistent with the RTP = subsessions proposal, but it would also be technically redundant. I'm not = sure exactly which comments in the paper you object to. I agree with you a= bout the purpose of BUNDLE > and that it works (with limitations) for its intended purpose. My unders= tanding is that BUNDLE is primarily intended for the case where a single RT= P session is shared across m lines. That is not true. That is only the "default" that we chose, and the limitat= ions in the draft are related to the case when you use a single RTP session= - they are not related to the BUNDLE mechanism as such. > There is no need for BUNDLE (and specifically the constrained PT assignme= nt) when you use another mechanism such as SHIM or RTP subsessions to segre= gate the > flows associated with each m line. Whether the grouping framework is app= licable is open for discussion. You still need something in order to use identical IP address:port values f= or multiple m- lines. > So perhaps we should separately discuss the grouping framework and constr= ained PT assignment procedures associated with BUNDLE to be sure we underst= and one another. > The source of our disagreement may be more what is meant by "BUNDLE" than= anything else. I have no problem redefining it if there is agreement to d= o so! We should separate the discussions on how the multiplexing is done on the R= TP level (which I think your draft mostly focuses on) and how it is signale= d in SDP. Regards, Christer ________________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 04, 2012 2:23 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi Richard, I will not comment on the RTP aspects of your proposal, but I don't underst= and your comments regarding BUNDLE. The core purpose of BUNDLE is to allow the usage of identical IP address:po= rt information for multiple m- lines. It is true that BUNDLE defines that, by default, all media belong to the sa= me RTP session. But, nothing prevents you from using BUNDLE also with multi= ple RTP sessions, RTP "subsession" etc. You simply need an extension mechan= ism to indicate/negotiate such usage (in your case the ssrc-prefix could p= erhaps be used for that). Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ejzak, Richard P (Richard) Sent: 4. kes=E4kuuta 2012 2:10 To: rtcweb@ietf.org Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. I am sen= ding this notice to rtcweb since this is the group that triggered recent wo= rk on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. It = might be useful to discuss the ideas in the ID before avtcore meets in Vanc= ouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard) Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration. There are sup= erficial similarities with an expired draft from last year in http://tools.= ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a differ= ent take on the use of SSRC as the basis for multi session multiplexing tha= t I think is superior and worthy of consideration as a potential replacemen= t for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. The IETF Secretariat= From richard.ejzak@alcatel-lucent.com Mon Jun 4 09:35:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525B821F879A for ; Mon, 4 Jun 2012 09:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.216 X-Spam-Level: X-Spam-Status: No, score=-8.216 tagged_above=-999 required=5 tests=[AWL=-1.967, BAYES_00=-2.599, HELO_EQ_FR=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 hRCjogwjJAa3 for ; Mon, 4 Jun 2012 09:35:48 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4D121F8794 for ; Mon, 4 Jun 2012 09:35:47 -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 q54GZi81018463 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Jun 2012 18:35:44 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Jun 2012 18:35:44 +0200 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 4 Jun 2012 12:35:42 -0400 From: "Ejzak, Richard P (Richard)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: AQHNQmyB4VpB676arUayTigsDre+oJbqVOAg Date: Mon, 4 Jun 2012 16:35:40 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92FC44E@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DD@ESESSCMS0356.eemea.ericsson.se> <03FBA798AC24E3498B74F47FD082A92FC38D@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C70C@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92FC3C8@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C457B13C0@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:35:49 -0000 Hi Christer, I just want to be clear what you mean by "BUNDLE". I assume here that you = refer to the use of the grouping mechanism and NOT necessarily the use of d= isjoint payload type values? Correct me if I am wrong: So you propose that the SDP grouping mechanism would be used regardless of = the RTP multiplexing scheme employed to indicate that some form of multiple= xing is to be used and to identify which lines are grouped together. If no= other mechanism is agreed, then multiplexing based on payload type is assu= med. If ssrc-prefix values are successfully negotiated then RTP subsession= s are used. If SHIM is successfully negotiated then SHIM is used. (This a= ll depends on which schemes are ultimately supported.) I have no objection to this approach in principle but am not convinced that= we need to support all of these multiplexing schemes. BR, Richard -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 04, 2012 11:10 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi Richard, > I agree with you that we should separate the discussion of how multiplexi= ng is done at the RTP level from=20 > how it is signaled in SDP. My draft addresses both aspects by describing= how to partition the SSRC space=20 > between m lines at the RTP level and how to signal that use in SDP using = a new "ssrc-prefix" attribute. Sure. But as far as the IP address:port re-use is concerned, I think you sh= ould use BUNDLE. > With the use of the ssrc-prefix attribute to identify RTP subsessions it = is not absolutely necessary to use the=20 > grouping framework to indicate bundling, since the ssrc-prefix attribute = implicitly indicates the bundling. =20 > These two mechanisms are compatible but redundant. I see no reason for having two mechanisms to do the same thing, and in gene= ral I also think we should try to avoid implicit indications. If often caus= es troubles later on. Using BUNDLE would also make it easier to define fallback behavior. For exa= mple, you could say that if the SDP answerer does not support the ssrc-pref= ix, but it does support BUNDLE, the fallback would be default BUNDLE behavi= or. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 04, 2012 8:54 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi, > I agree that BUNDLE in its current form would be consistent with the RTP = subsessions proposal, but it would also be technically redundant. I'm not = sure exactly which comments in the paper you object to. I agree with you a= bout the purpose of BUNDLE > and that it works (with limitations) for its intended purpose. My unders= tanding is that BUNDLE is primarily intended for the case where a single RT= P session is shared across m lines. That is not true. That is only the "default" that we chose, and the limitat= ions in the draft are related to the case when you use a single RTP session= - they are not related to the BUNDLE mechanism as such. > There is no need for BUNDLE (and specifically the constrained PT assignme= nt) when you use another mechanism such as SHIM or RTP subsessions to segre= gate the > flows associated with each m line. Whether the grouping framework is app= licable is open for discussion. You still need something in order to use identical IP address:port values f= or multiple m- lines. > So perhaps we should separately discuss the grouping framework and constr= ained PT assignment procedures associated with BUNDLE to be sure we underst= and one another. > The source of our disagreement may be more what is meant by "BUNDLE" than= anything else. I have no problem redefining it if there is agreement to d= o so! We should separate the discussions on how the multiplexing is done on the R= TP level (which I think your draft mostly focuses on) and how it is signale= d in SDP. Regards, Christer ________________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 04, 2012 2:23 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi Richard, I will not comment on the RTP aspects of your proposal, but I don't underst= and your comments regarding BUNDLE. The core purpose of BUNDLE is to allow the usage of identical IP address:po= rt information for multiple m- lines. It is true that BUNDLE defines that, by default, all media belong to the sa= me RTP session. But, nothing prevents you from using BUNDLE also with multi= ple RTP sessions, RTP "subsession" etc. You simply need an extension mechan= ism to indicate/negotiate such usage (in your case the ssrc-prefix could p= erhaps be used for that). Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ejzak, Richard P (Richard) Sent: 4. kes=E4kuuta 2012 2:10 To: rtcweb@ietf.org Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. I am sen= ding this notice to rtcweb since this is the group that triggered recent wo= rk on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. It = might be useful to discuss the ideas in the ID before avtcore meets in Vanc= ouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard) Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration. There are sup= erficial similarities with an expired draft from last year in http://tools.= ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a differ= ent take on the use of SSRC as the basis for multi session multiplexing tha= t I think is superior and worthy of consideration as a potential replacemen= t for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. The IETF Secretariat From christer.holmberg@ericsson.com Mon Jun 4 10:26:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C1921F8670 for ; Mon, 4 Jun 2012 10:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, 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 DiRCM5JdyVNV for ; Mon, 4 Jun 2012 10:26:40 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 72C9F21F8664 for ; Mon, 4 Jun 2012 10:26:39 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-7f-4fccefce631a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 46.FD.11869.ECFECCF4; Mon, 4 Jun 2012 19:26:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 4 Jun 2012 19:26:38 +0200 From: Christer Holmberg To: "Ejzak, Richard P (Richard)" , "rtcweb@ietf.org" Date: Mon, 4 Jun 2012 19:26:37 +0200 Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: AQHNQmyB4VpB676arUayTigsDre+oJbqVOAggAASTWk= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C457B13C4@ESESSCMS0356.eemea.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C2DD@ESESSCMS0356.eemea.ericsson.se> <03FBA798AC24E3498B74F47FD082A92FC38D@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C70C@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92FC3C8@US70UWXCHMBA05.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C0@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92FC44E@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC44E@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre6592f8Dd48UbXobQi3WPuvnd2B yaP12V5WjyVLfjIFMEVx2aSk5mSWpRbp2yVwZTy9/I29YL1LxYVzzg2ML826GDk5JARMJH5t vMQKYYtJXLi3nq2LkYtDSOAUo8SdBxOYIZwFjBI/Xt9i72Lk4GATsJDo/qcN0iAikCXx9fMU ZhCbRUBF4sCfqUwgJcIC7hILz0tDlHhI/Ngyhx3CtpJYsuAZG4jNKxAucen2RhaI8atZJPZc +Q12BKdApMT0HV1gRYxAB30/tYYJxGYWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKUS8qcad9 PSNEvZ7EjalT2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxCucmZuak lxvppRZlJhcX5+fpFaduYgTGx8Etv1V3MN45J3KIUZqDRUmc13rrHn8hgfTEktTs1NSC1KL4 otKc1OJDjEwcnFINjB7takt64mTDLEom/dQRmZXKVmkgpBsaqpjK9XPh/u89lew9fIE/Be76 yml4hdnmzuJ7tzaKX7+8dydT6xKlNx8ff59zOexqvKXjh6L2BY8/vb2uuD3l19Qfd2oPBf+R eSf1ge2qX+shqXbxxztmz0//H6Y0+7PR/qLGlcEdAbf+Td9Wvr/mkBJLcUaioRZzUXEiAJ9F MOJdAgAA Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 17:26:41 -0000 Hi, > I just want to be clear what you mean by "BUNDLE". I assume here that yo= u refer to the use of the grouping mechanism and NOT necessarily the use of= disjoint payload type values? Correct. > Correct me if I am wrong: > So you propose that the SDP grouping mechanism would be used regardless o= f the RTP multiplexing scheme employed to indicate that some form of multip= lexing is to be used and to identify which lines are grouped together. Correct. > If no other mechanism is agreed, then multiplexing based on payload type = is assumed. Yes. The details of that, however, is something that the community will hav= e to discuss and agree upon. My point was that it would be easier to define= a fallback if we use a single mechanism for bundling m- lines together. > If ssrc-prefix values are successfully negotiated then RTP subsessions ar= e used. If SHIM is successfully negotiated then SHIM is used. (This all d= epends on which schemes are ultimately supported.) Correct. > I have no objection to this approach in principle but am not convinced th= at we need to support all of these multiplexing schemes. That is a separate discussion :) Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 04, 2012 11:10 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi Richard, > I agree with you that we should separate the discussion of how multiplexi= ng is done at the RTP level from > how it is signaled in SDP. My draft addresses both aspects by describing= how to partition the SSRC space > between m lines at the RTP level and how to signal that use in SDP using = a new "ssrc-prefix" attribute. Sure. But as far as the IP address:port re-use is concerned, I think you sh= ould use BUNDLE. > With the use of the ssrc-prefix attribute to identify RTP subsessions it = is not absolutely necessary to use the > grouping framework to indicate bundling, since the ssrc-prefix attribute = implicitly indicates the bundling. > These two mechanisms are compatible but redundant. I see no reason for having two mechanisms to do the same thing, and in gene= ral I also think we should try to avoid implicit indications. If often caus= es troubles later on. Using BUNDLE would also make it easier to define fallback behavior. For exa= mple, you could say that if the SDP answerer does not support the ssrc-pref= ix, but it does support BUNDLE, the fallback would be default BUNDLE behavi= or. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 04, 2012 8:54 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi, > I agree that BUNDLE in its current form would be consistent with the RTP = subsessions proposal, but it would also be technically redundant. I'm not = sure exactly which comments in the paper you object to. I agree with you a= bout the purpose of BUNDLE > and that it works (with limitations) for its intended purpose. My unders= tanding is that BUNDLE is primarily intended for the case where a single RT= P session is shared across m lines. That is not true. That is only the "default" that we chose, and the limitat= ions in the draft are related to the case when you use a single RTP session= - they are not related to the BUNDLE mechanism as such. > There is no need for BUNDLE (and specifically the constrained PT assignme= nt) when you use another mechanism such as SHIM or RTP subsessions to segre= gate the > flows associated with each m line. Whether the grouping framework is app= licable is open for discussion. You still need something in order to use identical IP address:port values f= or multiple m- lines. > So perhaps we should separately discuss the grouping framework and constr= ained PT assignment procedures associated with BUNDLE to be sure we underst= and one another. > The source of our disagreement may be more what is meant by "BUNDLE" than= anything else. I have no problem redefining it if there is agreement to d= o so! We should separate the discussions on how the multiplexing is done on the R= TP level (which I think your draft mostly focuses on) and how it is signale= d in SDP. Regards, Christer ________________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 04, 2012 2:23 AM To: Ejzak, Richard P (Richard); rtcweb@ietf.org Subject: RE: [rtcweb] draft on media multiplexing submitted to AVTCORE Hi Richard, I will not comment on the RTP aspects of your proposal, but I don't underst= and your comments regarding BUNDLE. The core purpose of BUNDLE is to allow the usage of identical IP address:po= rt information for multiple m- lines. It is true that BUNDLE defines that, by default, all media belong to the sa= me RTP session. But, nothing prevents you from using BUNDLE also with multi= ple RTP sessions, RTP "subsession" etc. You simply need an extension mechan= ism to indicate/negotiate such usage (in your case the ssrc-prefix could p= erhaps be used for that). Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ejzak, Richard P (Richard) Sent: 4. kes=E4kuuta 2012 2:10 To: rtcweb@ietf.org Subject: [rtcweb] draft on media multiplexing submitted to AVTCORE Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. I am sen= ding this notice to rtcweb since this is the group that triggered recent wo= rk on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. It = might be useful to discuss the ideas in the ID before avtcore meets in Vanc= ouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard) Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration. There are sup= erficial similarities with an expired draft from last year in http://tools.= ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a differ= ent take on the use of SSRC as the basis for multi session multiplexing tha= t I think is superior and worthy of consideration as a potential replacemen= t for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. The IETF Secretariat= From harald@alvestrand.no Mon Jun 4 11:42:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E675C11E80B6 for ; Mon, 4 Jun 2012 11:42:40 -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=[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 U6jpEsdpC6me for ; Mon, 4 Jun 2012 11:42:38 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A7A5811E80B5 for ; Mon, 4 Jun 2012 11:42:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B80539E146; Mon, 4 Jun 2012 20:42:36 +0200 (CEST) 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 ddwtpfyX+8vj; Mon, 4 Jun 2012 20:42:33 +0200 (CEST) Received: from [10.130.3.66] (4.234.241.83.in-addr.dgcsystems.net [83.241.234.4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9763539E062; Mon, 4 Jun 2012 20:42:33 +0200 (CEST) Message-ID: <4FCD0198.2040307@alvestrand.no> Date: Mon, 04 Jun 2012 20:42:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ejzak, Richard P (Richard)" References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------020905030208080109020004" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 18:42:41 -0000 This is a multi-part message in MIME format. --------------020905030208080109020004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Richard, having scanned your draft: - I still fundamentally think that the partition of media types into separate RTP sessions was a design mistake that we should seek to rectify, not promulgate, and additional complexity like what you propose for perpetuating the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-sess-neutral for details. - When we have parts of the ecosystem that have code that is written on the assumption that the SSRC space is a 32-bit flat space, I think the partitioning of that space into subspaces as you propose is likely to lead to "interesting" bugs. We should reinforce the randomness and flatness of the SSRC space, not partition it. - You say "The biggest problem with BUNDLE is that it is difficult to partition the RTP streams associated with different media lines since this requires filtering on sets of payload type values. RTP subsessions is superior for this purpose since it is only necessary to screen for a single value in the first 16 bits". This assumes that the partitioning associated with different media lines is a good thing. I claim that it is not. If there are no bigger problems than that with BUNDLE, I would prefer to stick with that approach. On 06/04/2012 01:09 AM, Ejzak, Richard P (Richard) wrote: > > Please see the mail attached below that I just sent to avtcore > announcing a personal ID I just submitted on the topic of media > multiplexing. I am sending this notice to rtcweb since this is the > group that triggered recent work on RTP multiplexing. > > I also request the rtcweb chairs consider giving me some time to > present this work at next week's interim meeting if there is time on > the agenda. It might be useful to discuss the ideas in the ID before > avtcore meets in Vancouver. > > Richard > > -----Original Message----- > From: Ejzak, Richard P (Richard) > Sent: Sunday, June 03, 2012 6:08 PM > To: 'avt@ietf.org' > Subject: [AVTCORE] multi session > draft-ejzak-avtcore-rtp-subsessions-00.txt > > http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt > > In response to the chairs' request for additional input on the multi > session issue, I have submitted this draft for your consideration. > There are superficial similarities with an expired draft from last > year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, > but my draft has a different take on the use of SSRC as the basis for > multi session multiplexing that I think is superior and worthy of > consideration as a potential replacement for BUNDLE and/or SHIM. > Please comment. > > Richard > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Sunday, June 03, 2012 5:16 PM > > To: Ejzak, Richard P (Richard) > > Subject: New Version Notification for > draft-ejzak-avtcore-rtp-subsessions-00.txt > > A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has > been successfully submitted by Richard Ejzak and posted to the IETF > repository. > > Filename: draft-ejzak-avtcore-rtp-subsessions > > Revision: 00 > > Title: Media multiplexing with Real-time Transport Protocol > (RTP) subsessions > > Creation date: 2012-06-04 > > WG ID: Individual Submission > > Number of pages: 9 > > Abstract: > > This document describes a means of multiplexing RTP streams having > > different media types within a single transport connection and how to > > represent this multiplexing option in SDP. This mechanism is an > > alternative to the BUNDLE and SHIM proposals currently under active > > consideration in AVTCORE. Instead of adding an extra multiplexing > > header as in SHIM to allow multiple RTP sessions within a single > > transport connection, or using the payload type field to separate > > different media streams within a single RTP session, this document > > describes how to partition the existing SSRC space to create RTP > > subsessions from a single RTP session. A filter can be used to > > identify each RTP subsession for different QoS handling as necessary. > > RTP subsessions can be treated like RTP sessions with a few > > restrictions. In particular, SSRC mapping may be needed when > > forwarding RTP streams into an RTP subsession to avoid SSRC > > conflicts, but there are few use cases in which this limitation is a > > concern and RTP subsessions can be disabled if necessary. > > The IETF Secretariat > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020905030208080109020004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Richard,
having scanned your draft:

- I still fundamentally think that the partition of media types into separate RTP sessions was a design mistake that we should seek to rectify, not promulgate, and additional complexity like what you propose for perpetuating the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-sess-neutral for details.

- When we have parts of the ecosystem that have code that is written on the assumption that the SSRC space is a 32-bit flat space, I think the partitioning of that space into subspaces as you propose is likely to lead to "interesting" bugs. We should reinforce the randomness and flatness of the SSRC space, not partition it.

- You say "The biggest problem with BUNDLE is that it is
   difficult to partition the RTP streams associated with different
   media lines since this requires filtering on sets of payload type
   values.  RTP subsessions is superior for this purpose since it is
   only necessary to screen for a single value in the first 16 bits".
This assumes that the partitioning associated with different media lines is a good thing.
I claim that it is not.

If there are no bigger problems than that with BUNDLE, I would prefer to stick with that approach.





On 06/04/2012 01:09 AM, Ejzak, Richard P (Richard) wrote:

Please see the mail attached below that I just sent to avtcore announcing a personal ID I just submitted on the topic of media multiplexing.  I am sending this notice to rtcweb since this is the group that triggered recent work on RTP multiplexing.

 

I also request the rtcweb chairs consider giving me some time to present this work at next week’s interim meeting if there is time on the agenda.  It might be useful to discuss the ideas in the ID before avtcore meets in Vancouver.

 

Richard

 

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: 'avt@ietf.org'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

 

http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt

 

In response to the chairs' request for additional input on the multi session issue, I have submitted this draft for your consideration.  There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a different take on the use of SSRC as the basis for multi session multiplexing that I think is superior and worthy of consideration as a potential replacement for BUNDLE and/or SHIM.  Please comment.

 

Richard

 

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

From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

Sent: Sunday, June 03, 2012 5:16 PM

To: Ejzak, Richard P (Richard)

Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

 

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been successfully submitted by Richard Ejzak and posted to the IETF repository.

 

Filename:   draft-ejzak-avtcore-rtp-subsessions

Revision:   00

Title:            Media multiplexing with Real-time Transport Protocol (RTP) subsessions

Creation date:    2012-06-04

WG ID:            Individual Submission

Number of pages: 9

 

Abstract:

   This document describes a means of multiplexing RTP streams having

   different media types within a single transport connection and how to

   represent this multiplexing option in SDP.  This mechanism is an

   alternative to the BUNDLE and SHIM proposals currently under active

   consideration in AVTCORE.  Instead of adding an extra multiplexing

   header as in SHIM to allow multiple RTP sessions within a single

   transport connection, or using the payload type field to separate

   different media streams within a single RTP session, this document

   describes how to partition the existing SSRC space to create RTP

   subsessions from a single RTP session.  A filter can be used to

   identify each RTP subsession for different QoS handling as necessary.

   RTP subsessions can be treated like RTP sessions with a few

   restrictions.  In particular, SSRC mapping may be needed when

   forwarding RTP streams into an RTP subsession to avoid SSRC

   conflicts, but there are few use cases in which this limitation is a

   concern and RTP subsessions can be disabled if necessary.

 

                                                                                 

 

 

The IETF Secretariat

 

 

 



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

--------------020905030208080109020004-- From richard.ejzak@alcatel-lucent.com Mon Jun 4 13:04:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC9311E80C9 for ; Mon, 4 Jun 2012 13:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.822 X-Spam-Level: X-Spam-Status: No, score=-9.822 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0SbGjWg4j+z for ; Mon, 4 Jun 2012 13:04:01 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5B54111E80BA for ; Mon, 4 Jun 2012 13:04:00 -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 q54K3wrG025162 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Jun 2012 22:03:58 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Jun 2012 22:03:58 +0200 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.235]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 4 Jun 2012 16:03:54 -0400 From: "Ejzak, Richard P (Richard)" To: Harald Alvestrand Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: Ac1B3fo89iycBsSlSNO3kxpjdRSOagAxVnAAAAcX3SA= Date: Mon, 4 Jun 2012 20:03:51 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCD0198.2040307@alvestrand.no> In-Reply-To: <4FCD0198.2040307@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92FC55AUS70UWXCHMBA05zamal_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:04:06 -0000 --_000_03FBA798AC24E3498B74F47FD082A92FC55AUS70UWXCHMBA05zamal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, While ideally we should be able to maintain the entire SSRC space for use b= y an RTP session, the current concept of BUNDLE breaks the model by mixing = what are otherwise different RTP sessions together. The scope of an RTP se= ssion is beyond just the transport connection on which bundling is occurrin= g (see the RTP session topology diagrams in RFC 3550). Even though RTP pac= kets with different payload types could potentially reuse the same SSRC val= ue, SSRC values cannot be independently assigned per m line with the curren= t BUNDLE scheme since RTCP packets can be identified only using SSRC values= (payload type is not a field in RTCP packets). So the bundled m lines hav= e to share a single SSRC space, thus increasing the likelihood of SSRC coll= ision and preventing use of the same SSRC value across m lines and ports (a= s some applications require). To avoid these problems, translators impleme= nting the current BUNDLE will generally need to do SSRC mapping anyway, so = BUNDLE cannot take full advantage of the "randomness and flatness of the SS= RC space". I have read your draft and should have referenced it in my paper. I agree = that different media types should be able to share the same transport conne= ction. But I also see a need to be able to apply differential treatment of= media types within the network. You disagree with the need to separate packets associated with different me= dia lines for differential treatment in the network. Nevertheless, this is= sue has been raised in RFC 3550 and numerous drafts since then as a legitim= ate issue in certain deployments. While I agree with you that there are si= gnificant use cases in which such differential treatment is not necessary, = there are others in which it can be very beneficial. It would be really un= fortunate if there were no way to support such use cases in rtcweb. Richard ________________________________ From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Monday, June 04, 2012 1:43 PM To: Ejzak, Richard P (Richard) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE Richard, having scanned your draft: - I still fundamentally think that the partition of media types into separa= te RTP sessions was a design mistake that we should seek to rectify, not pr= omulgate, and additional complexity like what you propose for perpetuating = the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-se= ss-neutral for details. - When we have parts of the ecosystem that have code that is written on the= assumption that the SSRC space is a 32-bit flat space, I think the partiti= oning of that space into subspaces as you propose is likely to lead to "int= eresting" bugs. We should reinforce the randomness and flatness of the SSRC= space, not partition it. - You say "The biggest problem with BUNDLE is that it is difficult to partition the RTP streams associated with different media lines since this requires filtering on sets of payload type values. RTP subsessions is superior for this purpose since it is only necessary to screen for a single value in the first 16 bits". This assumes that the partitioning associated with different media lines is= a good thing. I claim that it is not. If there are no bigger problems than that with BUNDLE, I would prefer to st= ick with that approach. On 06/04/2012 01:09 AM, Ejzak, Richard P (Richard) wrote: Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. I am sen= ding this notice to rtcweb since this is the group that triggered recent wo= rk on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. It = might be useful to discuss the ideas in the ID before avtcore meets in Vanc= ouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard) Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration. There are sup= erficial similarities with an expired draft from last year in http://tools.= ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a differ= ent take on the use of SSRC as the basis for multi session multiplexing tha= t I think is superior and worthy of consideration as a potential replacemen= t for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. The IETF Secretariat _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_03FBA798AC24E3498B74F47FD082A92FC55AUS70UWXCHMBA05zamal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Harald,

While ideally we should be able to mai= ntain the entire SSRC space for use by an RTP session, the current concept = of BUNDLE breaks the model by mixing what are otherwise different RTP sessions together.  = The scope of an RTP session is beyond just the transport connection on whic= h bundling is occurring (see the RTP session topology diagrams in RFC 3550)= .  Even though RTP packets with different payload types could potentially reuse the same SSRC value, SSRC values can= not be independently assigned per m line with the current BUNDLE scheme sin= ce RTCP packets can be identified only using SSRC values (payload type is n= ot a field in RTCP packets).  So the bundled m lines have to share a single SSRC space, thus increasing the= likelihood of SSRC collision and preventing use of the same SSRC value acr= oss m lines and ports (as some applications require).  To avoid these = problems, translators implementing the current BUNDLE will generally need to do SSRC mapping anyway, so BUNDLE ca= nnot take full advantage of the “randomness and flatness of the SSRC = space”.

 

I have read your draft and should have= referenced it in my paper.  I agree that different media types should= be able to share the same transport connection.  But I also see a need to be able to apply diff= erential treatment of media types within the network.

 

You disagree with the need to separate= packets associated with different media lines for differential treatment i= n the network.  Nevertheless, this issue has been raised in RFC 3550 and numerous drafts since then as a= legitimate issue in certain deployments.  While I agree with you that= there are significant use cases in which such differential treatment is no= t necessary, there are others in which it can be very beneficial.  It would be really unfortunate if there w= ere no way to support such use cases in rtcweb.

 

Richard

 

 

= From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Monday, June 04, 2012 = 1:43 PM
To: Ejzak, Richard P (Richar= d)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] draft = on media multiplexing submitted to AVTCORE

 

Richard,
having scanned your draft:

- I still fundamentally think that the partition of media types into separa= te RTP sessions was a design mistake that we should seek to rectify, not pr= omulgate, and additional complexity like what you propose for perpetuating = the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-sess-neutral for details.

- When we have parts of the ecosystem that have code that is written on the= assumption that the SSRC space is a 32-bit flat space, I think the partiti= oning of that space into subspaces as you propose is likely to lead to &quo= t;interesting" bugs. We should reinforce the randomness and flatness of the SSRC space, not partition it.

- You say "The biggest problem with BUNDLE is that it is
   difficult to partition the RTP streams associated with differe= nt
   media lines since this requires filtering on sets of payload t= ype
   values.  RTP subsessions is superior for this purpose sin= ce it is
   only necessary to screen for a single value in the first 16 bi= ts".
This assumes that the partitioning associated with different media lines is= a good thing.
I claim that it is not.

If there are no bigger problems than that with BUNDLE, I would prefer to st= ick with that approach.





On 06/04/2012 01:09 AM, Ejzak, Richard P (Richard) wrote:

Please see the mail attached below that I just sent to avtcore announcing a perso= nal ID I just submitted on the topic of media multiplexing.  I am send= ing this notice to rtcweb since this is the group that triggered recent wor= k on RTP multiplexing.

 

I also request the rtcweb chairs consider giving = me some time to present this work at next week’s interim meeting if t= here is time on the agenda.  It might be useful to discuss the ideas in the ID before avtcore mee= ts in Vancouv= er.

 

Richard

 

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: 'avt@ietf.org'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt=

 =

http://ww= w.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt

 =

In response to the chairs' request fo= r additional input on the multi session issue, I have submitted this draft = for your consideration.  There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my d= raft has a different take on the use of SSRC as the basis for multi session= multiplexing that I think is superior and worthy of consideration as a pot= ential replacement for BUNDLE and/or SHIM.  Please comment.

 =

Richard

 =

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

From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

Sent: Sunday, June 03, 2012 5:16 PM

To: Ejzak, Richard P (Richard)<= /u1:p>

Subject: New Version Notification for= draft-ejzak-avtcore-rtp-subsessions-00.txt<= /font>

 =

A new version of I-D, draft-ejzak-avt= core-rtp-subsessions-00.txt has been successfully submitted by Richard Ejza= k and posted to the IETF repository.<= /p>

 =

Filename:   draft-ejzak-avt= core-rtp-subsessions

Revision:   00=

Title:     &= nbsp;      Media multiplexing with Real-time Trans= port Protocol (RTP) subsessions

Creation date:    2012= -06-04

WG ID:     &= nbsp;      Individual Submission=

Number of pages: 9<= /o:p>

 =

Abstract:

   This document describes = a means of multiplexing RTP streams having

   different media types wi= thin a single transport connection and how to

   represent this multiplex= ing option in SDP.  This mechanism is an

   alternative to the BUNDL= E and SHIM proposals currently under active<= /font>

   consideration in AVTCORE= .  Instead of adding an extra multiplexing

   header as in SHIM to all= ow multiple RTP sessions within a single

   transport connection, or= using the payload type field to separate

   different media streams = within a single RTP session, this document

   describes how to partiti= on the existing SSRC space to create RTP

   subsessions from a singl= e RTP session.  A filter can be used to=

   identify each RTP subses= sion for different QoS handling as necessary.

   RTP subsessions can be t= reated like RTP sessions with a few

   restrictions.  In p= articular, SSRC mapping may be needed when

   forwarding RTP streams i= nto an RTP subsession to avoid SSRC

   conflicts, but there are= few use cases in which this limitation is a=

   concern and RTP subsessi= ons can be disabled if necessary.

 =

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            

 =

 =

The IETF Secretariat

 

 

 




_______________________________________________=

rtcweb mailing list
rtcweb@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/rtcweb

 
--_000_03FBA798AC24E3498B74F47FD082A92FC55AUS70UWXCHMBA05zamal_-- From internet-drafts@ietf.org Mon Jun 4 16:10:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F378C11E812A; Mon, 4 Jun 2012 16:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 60Q2RbC+ZFC1; Mon, 4 Jun 2012 16:10:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8641511E80FA; Mon, 4 Jun 2012 16:10:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120604231047.28765.4001.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2012 16:10:47 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 23:10:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport an= d Use of RTP Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-03.txt Pages : 61 Date : 2012-06-04 The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ From harald@alvestrand.no Mon Jun 4 23:50:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C7C21F86B5 for ; Mon, 4 Jun 2012 23:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.156 X-Spam-Level: X-Spam-Status: No, score=-110.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 EH2+VJi02OnS for ; Mon, 4 Jun 2012 23:50:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 63C4121F86B2 for ; Mon, 4 Jun 2012 23:49:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 30B1C39E0A3; Tue, 5 Jun 2012 08:49:58 +0200 (CEST) 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 lKzurcqXSTXR; Tue, 5 Jun 2012 08:49:53 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BF10D39E089; Tue, 5 Jun 2012 08:49:53 +0200 (CEST) Message-ID: <4FCDAC11.7010304@alvestrand.no> Date: Tue, 05 Jun 2012 08:49:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ejzak, Richard P (Richard)" References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCD0198.2040307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------070005020709080801020704" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 06:50:04 -0000 This is a multi-part message in MIME format. --------------070005020709080801020704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/04/2012 10:03 PM, Ejzak, Richard P (Richard) wrote: > > Harald, > > While ideally we should be able to maintain the entire SSRC space for > use by an RTP session, the current concept of BUNDLE breaks the model > by mixing what are otherwise different RTP sessions together. The > scope of an RTP session is beyond just the transport connection on > which bundling is occurring (see the RTP session topology diagrams in > RFC 3550). > Yes, all parts of the RTP session need to agree on where the limits of the RTP session are. BUNDLE (the way it's currently written; Christer and I disagree on whether there is value in extending it to multiple sessions on the same address pairs) is about modifying the content of a single RTP session, it does not "mix different RTP sessions". > > Even though RTP packets with different payload types could > potentially reuse the same SSRC value, SSRC values cannot be > independently assigned per m line with the current BUNDLE scheme since > RTCP packets can be identified only using SSRC values (payload type is > not a field in RTCP packets). So the bundled m lines have to share a > single SSRC space, thus increasing the likelihood of SSRC collision > Yes. At 302 SSRCs in the same RTP session the chance of a collision is 50%. Applications that don't handle SSRC collisions are broken. > > and preventing use of the same SSRC value across m lines and ports (as > some applications require). > These applications have a design mistake, and should be recommended against. While they are still in use, they force the use of multiple RTP sessions where it's otherwise superfluous. Luckily there are not that many of them. > > To avoid these problems, translators implementing the current BUNDLE > will generally need to do SSRC mapping anyway, so BUNDLE cannot take > full advantage of the "randomness and flatness of the SSRC space". > RTP media translators in an RTP session where BUNDLE is used for setup need to set up their RTP sessions in such a way that either BUNDLE is used on all legs, or BUNDLE is used on no legs. This is because RTP media translators don't terminate RTP sessions. Gateways that terminate RTP sessions have to remap SSRCs anyway. No news here. > > I have read your draft and should have referenced it in my paper. I > agree that different media types should be able to share the same > transport connection. But I also see a need to be able to apply > differential treatment of media types within the network. > Yes, some applications need that. In that case, the simplest way (allowing per-flow prioritization) is to use different RTP sessions on different transport addresses. The next simplest way (using DiffServ) is to apply different DSCP markings on a per-packet basis. Both techniques are well established. Breaking up the SSRC space and applying differential treatment based on that requires rewriting the traffic management components. That's new code that needs to be deployed. I don't see the need. > > You disagree with the need to separate packets associated with > different media lines for differential treatment in the network. > No, I don't disagree at all with that need, and have said so many times. I disagree that this is a need that is present *all the time*, and disagree that this need is so omnipresent that we need to shape our architectures around it. > > Nevertheless, this issue has been raised in RFC 3550 and numerous > drafts since then as a legitimate issue in certain deployments. While > I agree with you that there are significant use cases in which such > differential treatment is not necessary, there are others in which it > can be very beneficial. It would be really unfortunate if there were > no way to support such use cases in rtcweb. > The point I was trying to make in rtp-sess-neutral is that the need for such differential treatment is orthogonal to the media types, and applications need to assign media streams to RTP sessions as the *applications*, not the *architecture*, think is adequate. That's really the focus of BUNDLE. But really, this discussion belongs on AVTCORE. > > Richard > > ------------------------------------------------------------------------ > > *From:*Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* Monday, June 04, 2012 1:43 PM > *To:* Ejzak, Richard P (Richard) > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] draft on media multiplexing submitted to AVTCORE > > Richard, > having scanned your draft: > > - I still fundamentally think that the partition of media types into > separate RTP sessions was a design mistake that we should seek to > rectify, not promulgate, and additional complexity like what you > propose for perpetuating the use of "separated" sessions is not > helpful. See draft-alvestrand-rtp-sess-neutral for details. > > - When we have parts of the ecosystem that have code that is written > on the assumption that the SSRC space is a 32-bit flat space, I think > the partitioning of that space into subspaces as you propose is likely > to lead to "interesting" bugs. We should reinforce the randomness and > flatness of the SSRC space, not partition it. > > - You say "The biggest problem with BUNDLE is that it is > difficult to partition the RTP streams associated with different > media lines since this requires filtering on sets of payload type > values. RTP subsessions is superior for this purpose since it is > only necessary to screen for a single value in the first 16 bits". > This assumes that the partitioning associated with different media > lines is a good thing. > I claim that it is not. > > If there are no bigger problems than that with BUNDLE, I would prefer > to stick with that approach. > > > > > > On 06/04/2012 01:09 AM, Ejzak, Richard P (Richard) wrote: > > Please see the mail attached below that I just sent to avtcore > announcing a personal ID I just submitted on the topic of media > multiplexing. I am sending this notice to rtcweb since this is the > group that triggered recent work on RTP multiplexing. > > I also request the rtcweb chairs consider giving me some time to > present this work at next week's interim meeting if there is time on > the agenda. It might be useful to discuss the ideas in the ID before > avtcore meets in Vancouver. > > Richard > > -----Original Message----- > From: Ejzak, Richard P (Richard) > Sent: Sunday, June 03, 2012 6:08 PM > To: 'avt@ietf.org ' > Subject: [AVTCORE] multi session > draft-ejzak-avtcore-rtp-subsessions-00.txt > > http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt > > In response to the chairs' request for additional input on the multi > session issue, I have submitted this draft for your consideration. > There are superficial similarities with an expired draft from last > year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, > but my draft has a different take on the use of SSRC as the basis for > multi session multiplexing that I think is superior and worthy of > consideration as a potential replacement for BUNDLE and/or SHIM. > Please comment. > > Richard > > -----Original Message----- > > From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org] > > Sent: Sunday, June 03, 2012 5:16 PM > > To: Ejzak, Richard P (Richard) > > Subject: New Version Notification for > draft-ejzak-avtcore-rtp-subsessions-00.txt > > A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has > been successfully submitted by Richard Ejzak and posted to the IETF > repository. > > Filename: draft-ejzak-avtcore-rtp-subsessions > > Revision: 00 > > Title: Media multiplexing with Real-time Transport Protocol > (RTP) subsessions > > Creation date: 2012-06-04 > > WG ID: Individual Submission > > Number of pages: 9 > > Abstract: > > This document describes a means of multiplexing RTP streams having > > different media types within a single transport connection and how to > > represent this multiplexing option in SDP. This mechanism is an > > alternative to the BUNDLE and SHIM proposals currently under active > > consideration in AVTCORE. Instead of adding an extra multiplexing > > header as in SHIM to allow multiple RTP sessions within a single > > transport connection, or using the payload type field to separate > > different media streams within a single RTP session, this document > > describes how to partition the existing SSRC space to create RTP > > subsessions from a single RTP session. A filter can be used to > > identify each RTP subsession for different QoS handling as necessary. > > RTP subsessions can be treated like RTP sessions with a few > > restrictions. In particular, SSRC mapping may be needed when > > forwarding RTP streams into an RTP subsession to avoid SSRC > > conflicts, but there are few use cases in which this limitation is a > > concern and RTP subsessions can be disabled if necessary. > > The IETF Secretariat > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------070005020709080801020704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/04/2012 10:03 PM, Ejzak, Richard P (Richard) wrote:

Harald,

While ideally we should be able to maintain the entire SSRC space for use by an RTP session, the current concept of BUNDLE breaks the model by mixing what are otherwise different RTP sessions together.  The scope of an RTP session is beyond just the transport connection on which bundling is occurring (see the RTP session topology diagrams in RFC 3550).

Yes, all parts of the RTP session need to agree on where the limits of the RTP session are. BUNDLE (the way it's currently written; Christer and I disagree on whether there is value in extending it to multiple sessions on the same address pairs) is about modifying the content of a single RTP session, it does not "mix different RTP sessions".

 Even though RTP packets with different payload types could potentially reuse the same SSRC value, SSRC values cannot be independently assigned per m line with the current BUNDLE scheme since RTCP packets can be identified only using SSRC values (payload type is not a field in RTCP packets).  So the bundled m lines have to share a single SSRC space, thus increasing the likelihood of SSRC collision

Yes. At 302 SSRCs in the same RTP session the chance of a collision is 50%. Applications that don't handle SSRC collisions are broken.

and preventing use of the same SSRC value across m lines and ports (as some applications require).

These applications have a design mistake, and should be recommended against. While they are still in use, they force the use of multiple RTP sessions where it's otherwise superfluous. Luckily there are not that many of them.

  To avoid these problems, translators implementing the current BUNDLE will generally need to do SSRC mapping anyway, so BUNDLE cannot take full advantage of the “randomness and flatness of the SSRC space”.

RTP media translators in an RTP session where BUNDLE is used for setup need to set up their RTP sessions in such a way that either BUNDLE is used on all legs, or BUNDLE is used on no legs. This is because RTP media translators don't terminate RTP sessions.

Gateways that terminate RTP sessions have to remap SSRCs anyway. No news here.

 

I have read your draft and should have referenced it in my paper.  I agree that different media types should be able to share the same transport connection.  But I also see a need to be able to apply differential treatment of media types within the network.

Yes, some applications need that.
 In that case, the simplest way (allowing per-flow prioritization) is to use different RTP sessions on different transport addresses.
The next simplest way (using DiffServ) is to apply different DSCP markings on a per-packet basis. Both techniques are well established.

Breaking up the SSRC space and applying differential treatment based on that requires rewriting the traffic management components. That's new code that needs to be deployed. I don't see the need.

 

You disagree with the need to separate packets associated with different media lines for differential treatment in the network.

No, I don't disagree at all with that need, and have said so many times. I disagree that this is a need that is present *all the time*, and disagree that this need is so omnipresent that we need to shape our architectures around it.

 Nevertheless, this issue has been raised in RFC 3550 and numerous drafts since then as a legitimate issue in certain deployments.  While I agree with you that there are significant use cases in which such differential treatment is not necessary, there are others in which it can be very beneficial.  It would be really unfortunate if there were no way to support such use cases in rtcweb.

The point I was trying to make in rtp-sess-neutral is that the need for such differential treatment is orthogonal to the media types, and applications need to assign media streams to RTP sessions as the *applications*, not the *architecture*, think is adequate. That's really the focus of BUNDLE.

But really, this discussion belongs on AVTCORE.

 

Richard

 

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Monday, June 04, 2012 1:43 PM
To: Ejzak, Richard P (Richard)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE

 

Richard,
having scanned your draft:

- I still fundamentally think that the partition of media types into separate RTP sessions was a design mistake that we should seek to rectify, not promulgate, and additional complexity like what you propose for perpetuating the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-sess-neutral for details.

- When we have parts of the ecosystem that have code that is written on the assumption that the SSRC space is a 32-bit flat space, I think the partitioning of that space into subspaces as you propose is likely to lead to "interesting" bugs. We should reinforce the randomness and flatness of the SSRC space, not partition it.

- You say "The biggest problem with BUNDLE is that it is
   difficult to partition the RTP streams associated with different
   media lines since this requires filtering on sets of payload type
   values.  RTP subsessions is superior for this purpose since it is
   only necessary to screen for a single value in the first 16 bits".
This assumes that the partitioning associated with different media lines is a good thing.
I claim that it is not.

If there are no bigger problems than that with BUNDLE, I would prefer to stick with that approach.





On 06/04/2012 01:09 AM, Ejzak, Richard P (Richard) wrote:

Please see the mail attached below that I just sent to avtcore announcing a personal ID I just submitted on the topic of media multiplexing.  I am sending this notice to rtcweb since this is the group that triggered recent work on RTP multiplexing.

 

I also request the rtcweb chairs consider giving me some time to present this work at next week’s interim meeting if there is time on the agenda.  It might be useful to discuss the ideas in the ID before avtcore meets in Vancouver.

 

Richard

 

-----Original Message-----
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08 PM
To: 'avt@ietf.org'
Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

 

http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt

 

In response to the chairs' request for additional input on the multi session issue, I have submitted this draft for your consideration.  There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a different take on the use of SSRC as the basis for multi session multiplexing that I think is superior and worthy of consideration as a potential replacement for BUNDLE and/or SHIM.  Please comment.

 

Richard

 

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

From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

Sent: Sunday, June 03, 2012 5:16 PM

To: Ejzak, Richard P (Richard)

Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

 

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been successfully submitted by Richard Ejzak and posted to the IETF repository.

 

Filename:   draft-ejzak-avtcore-rtp-subsessions

Revision:   00

Title:            Media multiplexing with Real-time Transport Protocol (RTP) subsessions

Creation date:    2012-06-04

WG ID:            Individual Submission

Number of pages: 9

 

Abstract:

   This document describes a means of multiplexing RTP streams having

   different media types within a single transport connection and how to

   represent this multiplexing option in SDP.  This mechanism is an

   alternative to the BUNDLE and SHIM proposals currently under active

   consideration in AVTCORE.  Instead of adding an extra multiplexing

   header as in SHIM to allow multiple RTP sessions within a single

   transport connection, or using the payload type field to separate

   different media streams within a single RTP session, this document

   describes how to partition the existing SSRC space to create RTP

   subsessions from a single RTP session.  A filter can be used to

   identify each RTP subsession for different QoS handling as necessary.

   RTP subsessions can be treated like RTP sessions with a few

   restrictions.  In particular, SSRC mapping may be needed when

   forwarding RTP streams into an RTP subsession to avoid SSRC

   conflicts, but there are few use cases in which this limitation is a

   concern and RTP subsessions can be disabled if necessary.

 

                                                                                 

 

 

The IETF Secretariat

 

 

 




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

 


--------------070005020709080801020704-- From christer.holmberg@ericsson.com Tue Jun 5 00:12:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4DE11E80B7 for ; Tue, 5 Jun 2012 00:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 eT26c78btjoo for ; Tue, 5 Jun 2012 00:11:58 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2E77B21F8661 for ; Tue, 5 Jun 2012 00:11:57 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-d2-4fcdb13b68cf Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F3.0D.00702.B31BDCF4; Tue, 5 Jun 2012 09:11:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 5 Jun 2012 09:11:54 +0200 From: Christer Holmberg To: Harald Alvestrand , "Ejzak, Richard P (Richard)" Date: Tue, 5 Jun 2012 09:11:53 +0200 Thread-Topic: [rtcweb] draft on media multiplexing submitted to AVTCORE Thread-Index: Ac1C53rB0goLx9lvTl6hHPz5Tm8c2gAAZ6Eg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C45A1C906@ESESSCMS0356.eemea.ericsson.se> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCD0198.2040307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC11.7010304@alvestrand.no> In-Reply-To: <4FCDAC11.7010304@alvestrand.no> 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_7F2072F1E0DE894DA4B517B93C6A05852C45A1C906ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvra71xrP+BofbjCyO9XWxWfQ2hFus /dfO7sDs0fpsL6vHlQlXWD2WLPnJFMAcxWWTkpqTWZZapG+XwJXxb2cHU8HcuUwVDT3/2RsY l3xm7GLk5JAQMJG49GsKO4QtJnHh3no2EFtI4BSjxIP3Bl2MXED2AkaJw0uOAyU4ONgELCS6 /2mD1IgI5EtsWNrLCmIzC6hL3Fl8DmwOi4CKxKrvp8BsYQE3idOvrzFD1LtLzOlvZwYZIyJg JHHnoCFImFcgXOLJzqOMEGvfMko0t/uA2JwCuhKvX05kAbEZgU77fmoNE8QqcYlbT+YzQZws ILFkz3lmCFtU4uXjf6wQ9aISd9rXM0LU50tMX93EArFLUOLkzCcsExhFZyEZNQtJ2SwkZRBx HYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo3BuYmZOerm5XmpRZnJxcX6eXnHqJkZg9B3c 8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYDSPmz8p39z0 wscN56tK+HYnbv915YpE00zzuQ17Dq+OFOuX7dr8w/dQEr+cw/LVRzJE/B39iz/J8k7+zbmw eNf6upV3DBqWeYvsa7efUr3YtdMnzUvs6Zbr1dkvPpy0c/vBndwyacdjNdG1N9ktHih+Zsz0 XKkgXlzX05U+Z+mjDOaOs+KVrEosxRmJhlrMRcWJAJODHFyMAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 07:12:03 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C45A1C906ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Harald, While ideally we should be able to maintain the entire SSRC space for use b= y an RTP session, the current concept of BUNDLE breaks the model by mixing = what are otherwise different RTP sessions together. The scope of an RTP se= ssion is beyond just the transport connection on which bundling is occurrin= g (see the RTP session topology diagrams in RFC 3550). Yes, all parts of the RTP session need to agree on where the limits of the = RTP session are. BUNDLE (the way it's currently written; Christer and I dis= agree on whether there is value in extending it to multiple sessions on the= same address pairs) is about modifying the content of a single RTP session= , it does not "mix different RTP sessions". I am not sure whether I disagree with you. Yes, the BUNDLE mechanism can be= extended (which I DO think is good) to be used also for multiple sessions,= but I'll leave it to the RTP experts to discuss/decide what (if any) value= there is in using multiple sessions :) And, I even strongly agree with you that the RTP aspects of multiplexing sh= ould be discussed in AVTCORE :) Regards, Christer Even though RTP packets with different payload types could potentially reu= se the same SSRC value, SSRC values cannot be independently assigned per m = line with the current BUNDLE scheme since RTCP packets can be identified on= ly using SSRC values (payload type is not a field in RTCP packets). So the= bundled m lines have to share a single SSRC space, thus increasing the lik= elihood of SSRC collision Yes. At 302 SSRCs in the same RTP session the chance of a collision is 50%.= Applications that don't handle SSRC collisions are broken. and preventing use of the same SSRC value across m lines and ports (as some= applications require). These applications have a design mistake, and should be recommended against= . While they are still in use, they force the use of multiple RTP sessions = where it's otherwise superfluous. Luckily there are not that many of them. To avoid these problems, translators implementing the current BUNDLE will= generally need to do SSRC mapping anyway, so BUNDLE cannot take full advan= tage of the "randomness and flatness of the SSRC space". RTP media translators in an RTP session where BUNDLE is used for setup need= to set up their RTP sessions in such a way that either BUNDLE is used on a= ll legs, or BUNDLE is used on no legs. This is because RTP media translator= s don't terminate RTP sessions. Gateways that terminate RTP sessions have to remap SSRCs anyway. No news he= re. I have read your draft and should have referenced it in my paper. I agree = that different media types should be able to share the same transport conne= ction. But I also see a need to be able to apply differential treatment of= media types within the network. Yes, some applications need that. In that case, the simplest way (allowing per-flow prioritization) is to us= e different RTP sessions on different transport addresses. The next simplest way (using DiffServ) is to apply different DSCP markings = on a per-packet basis. Both techniques are well established. Breaking up the SSRC space and applying differential treatment based on tha= t requires rewriting the traffic management components. That's new code tha= t needs to be deployed. I don't see the need. You disagree with the need to separate packets associated with different me= dia lines for differential treatment in the network. No, I don't disagree at all with that need, and have said so many times. I = disagree that this is a need that is present *all the time*, and disagree t= hat this need is so omnipresent that we need to shape our architectures aro= und it. Nevertheless, this issue has been raised in RFC 3550 and numerous drafts s= ince then as a legitimate issue in certain deployments. While I agree with= you that there are significant use cases in which such differential treatm= ent is not necessary, there are others in which it can be very beneficial. = It would be really unfortunate if there were no way to support such use ca= ses in rtcweb. The point I was trying to make in rtp-sess-neutral is that the need for suc= h differential treatment is orthogonal to the media types, and applications= need to assign media streams to RTP sessions as the *applications*, not th= e *architecture*, think is adequate. That's really the focus of BUNDLE. But really, this discussion belongs on AVTCORE. Richard ________________________________ From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Monday, June 04, 2012 1:43 PM To: Ejzak, Richard P (Richard) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE Richard, having scanned your draft: - I still fundamentally think that the partition of media types into separa= te RTP sessions was a design mistake that we should seek to rectify, not pr= omulgate, and additional complexity like what you propose for perpetuating = the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-se= ss-neutral for details. - When we have parts of the ecosystem that have code that is written on the= assumption that the SSRC space is a 32-bit flat space, I think the partiti= oning of that space into subspaces as you propose is likely to lead to "int= eresting" bugs. We should reinforce the randomness and flatness of the SSRC= space, not partition it. - You say "The biggest problem with BUNDLE is that it is difficult to partition the RTP streams associated with different media lines since this requires filtering on sets of payload type values. RTP subsessions is superior for this purpose since it is only necessary to screen for a single value in the first 16 bits". This assumes that the partitioning associated with different media lines is= a good thing. I claim that it is not. If there are no bigger problems than that with BUNDLE, I would prefer to st= ick with that approach. On 06/04/2012 01:09 AM, Ejzak, Richard P (Richard) wrote: Please see the mail attached below that I just sent to avtcore announcing a= personal ID I just submitted on the topic of media multiplexing. I am sen= ding this notice to rtcweb since this is the group that triggered recent wo= rk on RTP multiplexing. I also request the rtcweb chairs consider giving me some time to present th= is work at next week's interim meeting if there is time on the agenda. It = might be useful to discuss the ideas in the ID before avtcore meets in Vanc= ouver. Richard -----Original Message----- From: Ejzak, Richard P (Richard) Sent: Sunday, June 03, 2012 6:08 PM To: 'avt@ietf.org' Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt In response to the chairs' request for additional input on the multi sessio= n issue, I have submitted this draft for your consideration. There are sup= erficial similarities with an expired draft from last year in http://tools.= ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a differ= ent take on the use of SSRC as the basis for multi session multiplexing tha= t I think is superior and worthy of consideration as a potential replacemen= t for BUNDLE and/or SHIM. Please comment. Richard -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Sunday, June 03, 2012 5:16 PM To: Ejzak, Richard P (Richard) Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-0= 0.txt A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been s= uccessfully submitted by Richard Ejzak and posted to the IETF repository. Filename: draft-ejzak-avtcore-rtp-subsessions Revision: 00 Title: Media multiplexing with Real-time Transport Protocol (RTP= ) subsessions Creation date: 2012-06-04 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary. The IETF Secretariat _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7F2072F1E0DE894DA4B517B93C6A05852C45A1C906ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Harald,

While i= deally we should be able to maintain the entire SSRC space for use by an RT= P session, the current concept of BUNDLE breaks the model by mixing what ar= e otherwise different RTP sessions together.  The scope of an RTP sess= ion is beyond just the transport connection on which bundling is occurring = (see the RTP session topology diagrams in RFC 3550).

<= p class=3DMsoNormal>Yes, all parts of the RTP session need to agree on where th= e limits of the RTP session are. BUNDLE (the way it's currently written; Ch= rister and I disagree on whether there is value in extending it to multiple= sessions on the same address pairs) is about modifying the content of a si= ngle RTP session, it does not "mix different RTP sessions".

I am not sure whether I disagree with you. Y= es, the BUNDLE mechanism can be extended (which I DO think is good) to be u= sed also for multiple sessions, but I’ll leave it to the RTP experts = to discuss/decide what (if any) value there is in using multiple sessions := )

 

And, I eve= n strongly agree with you that the RTP aspects of multiplexing should be di= scussed in AVTCORE :)

 <= /p>

Regards,

 

=

Christer

 

 

 

=

 Even though RTP packets with different payload= types could potentially reuse the same SSRC value, SSRC values cannot be i= ndependently assigned per m line with the current BUNDLE scheme since RTCP = packets can be identified only using SSRC values (payload type is not a fie= ld in RTCP packets).  So the bundled m lines have to share a single SS= RC space, thus increasing the likelihood of SSRC collision

Yes. At 302 SSRCs in the same RTP session the chance = of a collision is 50%. Applications that don't handle SSRC collisions are b= roken.

and preventing u= se of the same SSRC value across m lines and ports (as some applications re= quire).

These applications have a des= ign mistake, and should be recommended against. While they are still in use= , they force the use of multiple RTP sessions where it's otherwise superflu= ous. Luckily there are not that many of them.

=

  To avoid these problems, translators implemen= ting the current BUNDLE will generally need to do SSRC mapping anyway, so B= UNDLE cannot take full advantage of the “randomness and flatness of t= he SSRC space”.

RTP media trans= lators in an RTP session where BUNDLE is used for setup need to set up thei= r RTP sessions in such a way that either BUNDLE is used on all legs, or BUN= DLE is used on no legs. This is because RTP media translators don't termina= te RTP sessions.

Gateways that terminate RTP sessions have to remap = SSRCs anyway. No news here.

 

I have read your dr= aft and should have referenced it in my paper.  I agree that different= media types should be able to share the same transport connection.  B= ut I also see a need to be able to apply differential treatment of media ty= pes within the network.

Yes, some app= lications need that.
 In that case, the simplest way (allowing per-= flow prioritization) is to use different RTP sessions on different transpor= t addresses.
The next simplest way (using DiffServ) is to apply differen= t DSCP markings on a per-packet basis. Both techniques are well established= .

Breaking up the SSRC space and applying differential treatment bas= ed on that requires rewriting the traffic management components. That's new= code that needs to be deployed. I don't see the need.

 

You disagree with the need to separate packets associated with diff= erent media lines for differential treatment in the network.

No, I don't disagree at all with that need, and ha= ve said so many times. I disagree that this is a need that is present *all = the time*, and disagree that this need is so omnipresent that we need to sh= ape our architectures around it.

 Nevertheless, this issue has been raised in RFC 3550 and nu= merous drafts since then as a legitimate issue in certain deployments. &nbs= p;While I agree with you that there are significant use cases in which such= differential treatment is not necessary, there are others in which it can = be very beneficial.  It would be really unfortunate if there were no w= ay to support such use cases in rtcweb.

 

Richard

 

 

= From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Mon= day, June 04, 2012 1:43 PM
To: Ejzak, Richard P (Richard)
C= c: rtcweb@ietf.org
Subject= : Re: [rtcweb] draft on media multiplexing submitted to AVTCORE<= o:p>

 

Richard,
having scanned your draft:

- I still = fundamentally think that the partition of media types into separate RTP ses= sions was a design mistake that we should seek to rectify, not promulgate, = and additional complexity like what you propose for perpetuating the use of= "separated" sessions is not helpful. See draft-alvestrand-rtp-se= ss-neutral for details.

- When we have parts of the ecosystem that h= ave code that is written on the assumption that the SSRC space is a 32-bit = flat space, I think the partitioning of that space into subspaces as you pr= opose is likely to lead to "interesting" bugs. We should reinforc= e the randomness and flatness of the SSRC space, not partition it.

-= You say "The biggest problem with BUNDLE is that it is
  = ; difficult to partition the RTP streams associated with different
 = ;  media lines since this requires filtering on sets of payload type   values.  RTP subsessions is superior for this purpose s= ince it is
   only necessary to screen for a single value in t= he first 16 bits".
This assumes that the partitioning associated wi= th different media lines is a good thing.
I claim that it is not.
If there are no bigger problems than that with BUNDLE, I would prefer to s= tick with that approach.





On 06/04/2012 01:09 AM, Ejz= ak, Richard P (Richard) wrote:

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Please see= the mail attached below that I just sent to avtcore announcing a personal = ID I just submitted on the topic of media multiplexing.  I am sending = this notice to rtcweb since this is the group that triggered recent work on= RTP multiplexing.

 

I also request the rtcweb chairs consider giving me some t= ime to present this work at next week’s interim meeting if there is t= ime on the agenda.  It might be useful to discuss the ideas in the ID = before avtcore meets in Vancouver.

 <= /span>

Richard

&= nbsp;

-----Original Message---= --
From: Ejzak, Richard P (Richard)
Sent: Sunday, June 03, 2012 6:08= PM
To: 'avt@ietf.org'
Subject: [= AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

 

http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-= 00.txt

 <= /o:p>

In response to the chairs' request for add= itional input on the multi session issue, I have submitted this draft for y= our consideration.  There are superficial similarities with an expired= draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtp= mux-00.txt, but my draft has a different take on the use of SSRC as the= basis for multi session multiplexing that I think is superior and worthy o= f consideration as a potential replacement for BUNDLE and/or SHIM.  Pl= ease comment.

 

Richard

 

-----Or= iginal Message-----

From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=

Sent: Sunday, June 03, 2012 = 5:16 PM

To: Ejzak, Richard P (= Richard)

Subject: New Version = Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

 

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has= been successfully submitted by Richard Ejzak and posted to the IETF reposi= tory.

 =

Filename:   draft-ejzak-avtcore-rtp-s= ubsessions

Revision: &nbs= p; 00

Title:   =          Media multiplexing with Re= al-time Transport Protocol (RTP) subsessions

Creation date:    2012-06-04

WG ID:      &nb= sp;     Individual Submission

Number of pages: 9

 

Abstract:

   This document describ= es a means of multiplexing RTP streams having

   different media types within a single transpor= t connection and how to

 =   represent this multiplexing option in SDP.  This mechanism is a= n

   alternative to = the BUNDLE and SHIM proposals currently under active

<= p class=3DMsoPlainText>   consideration in AVTCORE.  Instead= of adding an extra multiplexing

   transport c= onnection, or using the payload type field to separate

   different media streams within a sing= le RTP session, this document

= =    describes how to partition the existing SSRC space to create R= TP

   subsessions fr= om a single RTP session.  A filter can be used to

   identify each RTP subsession for diff= erent QoS handling as necessary.

   restrictions.&nb= sp; In particular, SSRC mapping may be needed when

   forwarding RTP streams into an RTP subses= sion to avoid SSRC

  = ; conflicts, but there are few use cases in which this limitation is a

   concern and RTP subse= ssions can be disabled if necessary.

 

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   

 

 

The IETF Secretariat

=  

 

 



__________________________________=
_____________
rtcweb mailing list
rtcweb@ietf.orghttps://www.ietf= .org/mailman/listinfo/rtcweb

 

 

= --_000_7F2072F1E0DE894DA4B517B93C6A05852C45A1C906ESESSCMS0356e_-- From csp@csperkins.org Tue Jun 5 06:18:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E44121F8692 for ; Tue, 5 Jun 2012 06:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swiM8b+YtyAo for ; Tue, 5 Jun 2012 06:18:22 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7C67821F85EA for ; Tue, 5 Jun 2012 06:18:22 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SbteP-0000R5-k4; Tue, 05 Jun 2012 13:18:21 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4FCDAC11.7010304@alvestrand.no> Date: Tue, 5 Jun 2012 14:18:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <94DB3F99-8C0C-4B8D-8BB5-AB833AB89FE0@csperkins.org> References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCD0198.2040307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC11.7010304@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 13:18:23 -0000 On 5 Jun 2012, at 07:49, Harald Alvestrand wrote: > On 06/04/2012 10:03 PM, Ejzak, Richard P (Richard) wrote: ... >> Even though RTP packets with different payload types could = potentially reuse the same SSRC value, SSRC values cannot be = independently assigned per m line with the current BUNDLE scheme since = RTCP packets can be identified only using SSRC values (payload type is = not a field in RTCP packets). So the bundled m lines have to share a = single SSRC space, thus increasing the likelihood of SSRC collision >=20 > Yes. At 302 SSRCs in the same RTP session the chance of a collision is = 50%. Applications that don't handle SSRC collisions are broken. I agree that applications that don't handle SSRC collisions are broken, = but RFC 3550 Section 8.1 gives a vastly lower probability of collision. = Is there a mistake in the calculation in the RFC? --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Tue Jun 5 09:32:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460C021F86DE; Tue, 5 Jun 2012 09:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 EvK0CywywU4k; Tue, 5 Jun 2012 09:32:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF7321F8762; Tue, 5 Jun 2012 09:32:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120605163231.17702.31075.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2012 09:32:31 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 16:32:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Security Considerations for RTC-Web Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-03.txt Pages : 22 Date : 2012-06-05 The Real-Time Communications on the Web (RTC-Web) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTC-Web technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTC-Web communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the RTC-Web threat model and defines an architecture which provides security within that threat model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-security-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ From internet-drafts@ietf.org Tue Jun 5 09:33:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F1F21F8704; Tue, 5 Jun 2012 09:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 fgtuksRtxXzu; Tue, 5 Jun 2012 09:33:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C1121F8773; Tue, 5 Jun 2012 09:33:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120605163314.18591.69528.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2012 09:33:14 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 16:33:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : RTCWEB Security Architecture Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-02.txt Pages : 20 Date : 2012-06-05 The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (e.g JavaScript). The major use cases for RTCWEB technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based soft phones) RTCWEB communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. [I-D.ietf-rtcweb- security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ From ekr@rtfm.com Tue Jun 5 09:50:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6886021F873E for ; Tue, 5 Jun 2012 09:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.027 X-Spam-Level: X-Spam-Status: No, score=-98.027 tagged_above=-999 required=5 tests=[AWL=-4.950, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, MANGLED_SAVELE=2.3, 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 eL3gfzTVpnzI for ; Tue, 5 Jun 2012 09:50:50 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B97D921F874C for ; Tue, 5 Jun 2012 09:50:49 -0700 (PDT) Received: by vcqp1 with SMTP id p1so3689684vcq.31 for ; Tue, 05 Jun 2012 09:50:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding :x-gm-message-state; bh=FmCZETTP0Vv3SiJHUM0GPNHObrWBIaqhY2WlDtMclkk=; b=J4Hgq4u0nqi810Tq6LAxmSK1Bf5vgKHUbGKKLcBwe/g2DZgkPY3pHJrn6FFz97EJnC Qv3QweihiQjK6Bg2wEzG2ToTilDv7CxZmFHbVt8Eo7fb0XBYBlN6lcL4yVKOCDqTWUwU qOil1McmDy+i4FbLifLilEtjyVV3CznICpVbucvwKfN9flu1Q/of+B/9gOOcVdXLuwPw Gm9/eHpy1p1jEHz5RkoNSsAu1Lg2e5HipFMNoJVfgkh7hzQpLh5xBUNndI6fBvB4pcib L4j668IK1PhVtAu385MNyOxARuaZQSEKtgXCqiweM03Kx8jPABw8pFMumujWnanzVE6u R+pw== Received: by 10.220.242.14 with SMTP id lg14mr17435931vcb.28.1338915049120; Tue, 05 Jun 2012 09:50:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 5 Jun 2012 09:50:08 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Tue, 5 Jun 2012 09:50:08 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl0cvBpDDcySmoBS6fBf2c9usVgvl0sNHYd2hmRhFteHadC5yaBGP5OIQsnSfqU+dUeWvQ9 Subject: [rtcweb] Fwd: Review of security documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 16:50:51 -0000 ---------- Forwarded message ---------- From: Eric Rescorla Date: Tue, Jun 5, 2012 at 9:36 AM Subject: Re: [rtcweb] Review of security documents To: Martin Thomson > =A0THOMSON: Martin, Thanks for your detailed review. Comments/responses below. Let me know if you think I have gotten something wrong. > HTTP/HTTPS > > S3, last paragraph before S3.1: > > =A0 [...], but realistically many sites do not run > =A0 HTTPS [RFC2818] and so our ability to defend against network > =A0 attackers is necessarily somewhat limited. > > This isn't especially relevant. > > Obviously, the standard class of problems with unsecured HTTP exist, but > within the context of this application, there aren't that many more that > this enables. =A0The example in S4.1.3 is not unique to this application. > It applies to any user consent that is tied to a particular web origin. > > In comparison to possibly visiting and _using_ a site operated by a web > attacker, this is not substantially worse, or requiring significantly > more effort to analyze. > > Of course, the only safe assumption is that you are talking to a web > attacker when using unsecured HTTP. > ((Aside: I'd be interested in learning how this might turn into an > attack on user consent. =A0Otherwise, this is a bit of a scary statement > to just drop in without support: > =A0 Note: =A0this issue is not restricted to PAGES > =A0 which contain mixed content. =A0If a page from a given origin ever > =A0 loads mixed content then it is possible for a network attacker to > =A0 infect the browser's notion of that origin semi-permanently.)) > > NETWORK ATTACKERS > > Same paragraph: > > =A0 [...], with the assumption that > =A0 protection against network attackers is provided by running HTTPS. > > Thankfully, the draft does not make this assumption. =A0Attacks on HTTP > are out of scope, but we still need to deal with network attackers. Thanks for catching this inconsistency. I'm taking the sum of these comments as "stop acting like you're not addressing HTTP." So, I rewrote this graf as: =A0 =A0 =A0 =A0Conventionally, we refer to either WEB ATTACKERS, who are ab= le =A0 =A0 =A0 =A0to induce you to visit their sites but do not control the =A0 =A0 =A0 =A0network, and NETWORK ATTACKERS, who are able to control your =A0 =A0 =A0 =A0network. Network attackers correspond to the "Internet Threat Model". Note that for = HTTP =A0 =A0 =A0 =A0traffic, a network attacker is also a Web attacker, since it =A0 =A0 =A0 =A0can inject traffic as if it were any non-HTTPS Web site. Thu= s, =A0 =A0 =A0 =A0when analyzing HTTP connections, we must assume that traffic =A0 =A0 =A0 =A0is going to the attacker. > TYPES OF CONSENT > > The document talks about consent in general as being important but it > doesn't do anything to address what specific consent is needed. > > I think that it has been well-established that consent is required for > access to input devices (e.g., camera/microphone). =A0The implication fro= m > S4.1 is that this is sufficient as well as necessary. =A0There is one > crucial piece of the argument that is absent: > > =A0 A site with access to camera or microphone could send media either to > =A0 itself or any site that indicates consent (see CORS). =A0Sending medi= a > =A0 over HTTP or thewebsocketprotocol is likely to perform less well than > =A0 is ideal, but it would work. > > Therefore, it's easy to draw the implicit conclusions of the draft, > namely: > =A01. a receipt consent mechanism like CORS is necessary, and > =A02. user consent for access to input devices is necessary _and_ > =A0 =A0 sufficient...for this mode. I've tried to address this some more in Section 4.1. > PRIVATE COMMUNICATIONS AND CONSENT > > The above assumes that the site has access to media. =A0That is, > permission for input devices is being granted to the site. =A0However, it > is possible to imagine a mode of communications where the site mediates > the creation of a secure channel, but does not have access to that > channel. IMO there are actually two issues here: (1) consent (2) peer authentication To give an example, I might be happy to have Gmail be able to access my camera and microphone without a big consent experience, but I still want to be able to have calls that I know Gmail can't listen in on in. That way I can have easy calls, but when I want security I can have it. I have tried to make this clear in the new text. > This changes the assumptions - and the nature of the consent - > dramatically. =A0S4.1.2 and security-arch@S5.2 covers this case, but > doesn't really properly emphasize just how different this is. > > Just as for the entirety of S4.1, the problem then becomes one of > unambiguous identification. =A0And UI. =A0From S4.1.2: > > =A0 Naturally, it is somewhat challenging to design UI > =A0 primitives which express this sort of policy. > > Complications include group calling. =A0How does the site ask for > permissions to talk to "a@b.com" and "x@y.net"? =A0How does such a > privilege persist? =A0Does it even make sense to persist at all? > Obviously, a conference of any significant size tends toward having a > bridge. =A0At that point, input devices are most likely granted to > "host.example.com". I don't actually think this is an issue at the WebRTC level. ISTM that there are two ways to do a multi-user call in WebRTC: (a) a set of individual calls, which the browser handles separately. (b) a call to a bridge which manifests as a call to someone other than a@b.com or x@y.net So in either case, not our problem. > TRULY PRIVATE COMMUNICATIONS > > Keeping the site out of the loop requires that the browser lock down > access to media recording. =A0The trick is to ensure that the media is > unmodified all the way from source to sink. =A0It's relatively easy to > ensure that media coming off the network is unmodified. > > It is harder to ensure that it did not get modified by a web attacker > prior to being put on the network. =A0That requires a verifiable assertio= n > from the remote user that it did not allow a web attacker access to see > or modify the stream prior to it being placed in the pipe. > > The distinction between media stream visibility and modifiability might > be worth discussing a little. =A0My initial thought is that it was not > especially useful in this context. =A0I can imagine work-arounds that > would enable features that depend on visibility such as recording where > authenticity is also desirable. Good point. I have added a new section to make this point. > IDENTIFICATION > > S4.1.1.1.1.1.1.1.1 asks the obvious question: > > =A0 [...] there is a question about whether the > =A0 user can know who they are talking to. > > When a site has access to your media, then you are talking to the site. > ...and anyone the site chooses to forward your media to. =A0This is > exactly what you get when you use SRTP security descriptions (and also > EKT, if you allow the site to insert keys). See above. > USER INTERACTION CONSIDERATIONS > > S4.1.1.2 hides two important UI considerations: > > =A0 [...] great care must be taken in the design of this interface > =A0 to avoid the users just clicking through > > and > > =A0 [...] the user > =A0 interface chrome must clearly display elements showing that the call > =A0 is continuing in order to avoid attacks where the calling site just > =A0 leaves it up indefinitely > > These are both massively important. =A0If there were a W3C companion > document, then it would make sense to include this sort of stuff there. > > More robust treatment would be nice for: > =A0a) the limitations of consent mechanisms > =A0b) providing appropriate feedback > > For the latter, this can get complicated. =A0I recall a discussion of the > geolocation API that lead to the conclusion that no UI feedback would be > provided. =A0I still believe that this was a poor choice. =A0This case be= ars > a certain amount of similarity to that discussion. =A0I should really joi= n > that media capture group... > > In any case, this probably needs at least basic treatment here, even if > that is just by reference. I agree we should say something about this, but I think it's best said in the W3C specs. I will work to produce something. > AUTHENTICATION MODELS > > (Crossing over into S4 of the security-arch document here to address the > use cases from S4.1.1.2 and S4.1.1.3.) > > It looks like there is an assumption in play here. =A0That is, there is > something like an IdP in use. =A0Calling a site (as opposed to a person) > is very much a case where the usual domain trust anchors are perfectly > adequate. =A0The site can offer an identical (or similar) certificate in > the DTLS handshake as it did with the HTTPS TLS handshake. > > Obviously, it's not as simple as just having this chain to a trust > anchor. =A0Any site that deployed TLSA (c.f. DANE WG) would require extra > checking. > > I'm surprised to see nothing on this particular use case. =A0It's a > particularly useful one. OK. I'll add something to the security-arch document. > CALL MEDIATION AND REPUTATION > > S4.1.1.3 contains a discussion about a case where the reputation of one > site is potentially affected by it mediating a call with a third party. > In the example, sites wouldn't want advertisements they display from > reflecting poorly on them. > > I don't see how this changes the current situation significantly. =A0Site > and ad networks work very hard to ensure that advertisements are > appropriate to the context in which they are shown. =A0Realtime calling > doesn't really change this situation in any meaningful way. > > A very big part of this is ensuring that the source of media is > correctly identified. =A0In part, this is the same problem we already > have. =A0In addition, sites need to take some responsibility for making > any necessary distinction sufficiently clear on their own interface. =A0I= n > this context, the burden lies with the ad network. Hmm... my experience is that sites and ad networks don't do that much vetting of JS, actually. I've done ad network studies where we put arbitrary JS that does a pile of XHR-type stuff in ads and nobody seemed to notice. > ((Aside. =A0I'm not sure that this is always true: > =A0 [...] sites which host > =A0 advertisements often learn very little about whether individual users > =A0 clicked through to the ads, or even which ads were presented > > That's true for ads in iframes, but then the reputation concern isn't > entirely applicable. =A0If the ads are served inline, then I would have t= o > assume that obfuscation of ad network content is the only protection > against the site learning about ad content and user interactions.)) Yes, that's correct. I added "in IFRAMEs". > COMMUNICATIONS CONSENT > > The idea that a target for a media flow consents is not binary in the > sense that ICE establishes. =A0Even with the addition of an expiration > time to ICE consent, there are two problems related to the volume of > packets that need addressing: > > The rate at which STUN Binding requests are generated in ICE is > dependent on the bandwidth available for media. =A0Because this > information comes from a web attacker, the browser cannot trust this > information. =A0The browser has to rate-limit Binding requests based on > its own information. =A0In practice, this probably has to be based on a > fixed rate. > > Even once the browser has validated consent, it has no idea _how much_ > media is OK to send. =A0The difference between 8kbps audio and 5Mbps high > definition video is enough to make many an internet connection melt. > RTCP feedback like TMMBR is good, but maybe those packets could be made > to get "lost" by a network attacker. =A0Plus, if we are going to offer a > data channel that doesn't use RTCP, then that option isn't available. So, this is definitely a real issue, but I'm not sure how far we want to go in doing something about it. My thought had been that we wouldn't attempt to obtain explicit consent for a particular bandwidth rate and instead assume that if the sending side is maliciously sending over-bandwidth that the receiving side will drop continuing consent probes and cause the connection to be torn down. That said, I think this is something we need to actually discuss, so I'll mark it an open issue and let's talk about it in the meeting as part of the continuing consent discussion. > BANDWIDTH LIMITING > > Bandwidth limiting is probably an important security feature that isn't > really covered, though you touch on it in the security considerations of > security-arch. See above. > SPECULATIVE STUFF > > Don't think that we need masking: TURN TCP probably has enough > protection already and that's the only TCP I can imagine having to use, > aside from HTTPS... I tend to agree, but I think it's worth leaving here as part of the analytical framework. > Don't think that we need some sort of implicit consent mechanism. =A0For > consent, I don't think that it's unreasonable to expect ICE-lite at a > minimum. Me neither. I think that's sort of what the -arch document suggests as well. > See thread on hiding IP addresses. =A0In order to avoid tracking via IP, > clients should not use the Internet. =A0I hear that Tor is somewhat handy > at making it possible to have cake that you can eat too. =A0That said, I'= m > not sure that that particular cake tastes all that nice... I'm not sure either, but.... what are you looking for he? > IdP > > MIXED CONTENT > > security-arch@S5.1 > > It might make sense to consider _all_ unsecured HTTP is being in the > same origin for the purposes of this. I'm not sure what you are suggesting? Seems like a big error to treat http://www.foo.com/ and http://www.bar.com/ as the same for consent purposes. > Furthermore, I subscribe to the view that mixed content =3D=3D unsecured. Hmm.... I mostly agree with this, but I think that web attackers are real.... > The idea that a page might become mixed content is a real concern. > Terminating the session is probably the only safe choice. > > Here's the thought process. =A0Initially, I thought that it might be > sufficient to prevent modifications to the session once a page goes > rogue. =A0At least then if a secure browser-to-browser pipe exists that > the page could not access prior to the poisoning, this pipe can continue > unmodified. =A0However, if one browser goes off the grid, then it can > simply exploit any renegotiation capabilities that exist in the > application to trigger changes through the signaling channel. =A0For > instance, EKT might allow the attacker to update keys. =A0Given that it > should also be possible to insert a relay (in one direction at least) by > providing faked "candidates", this cracks it wide open. =A0The more > renegotiation capabilities exist on the media path, the worse this is. I generally agree with this. > ICE TRANSACTION ID > > ...need only be hidden for Binding requests that are outstanding. > Successful requests need not be hidden. =A0(Note that this means meeting > all of the success criteria specified in RFC 5245.) Agreed. > ICE KEEPALIVES > > Are not sufficient, so don't require them. =A0Instead, require a repeat o= f > the connectivity check. =A0That ensures consent is refreshed and it also > means that the statement about ICE-Lite remains true, which would not be > so if another mechanism were used. This seems like it's an open issue to discuss during the interim, since I know there have been some questions here. > UNLINKABILITY > > security-arch@S5.5 > > Nothing on this in the security doc. =A0What is the goal here? I'm not sure I understand the question. I want to be able to make calls to people without having them linked? > Minting a new key can be expensive. =A0How do you prevent sites from > pushing the button too often and causing a different sort of problem? What do you mean? The site can always cause the browser to burn arbitrary amounts of CPU (though this typically will eventually cause the browser to make some kind of sad face), just by infinite looping. -Ekr From ekr@rtfm.com Tue Jun 5 09:51:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F7421F8768 for ; Tue, 5 Jun 2012 09:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 O0vNj4jENZYV for ; Tue, 5 Jun 2012 09:51:02 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6BBD21F875D for ; Tue, 5 Jun 2012 09:51:01 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id p1so3689684vcq.31 for ; Tue, 05 Jun 2012 09:51:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding :x-gm-message-state; bh=wzLMfnaY4ZBZPdcoGbYostQNkKPZM8fjmS3ATJayQQA=; b=VLPy5I+mz/Mtpy/uZl3IYAtvhCkjpd+5EyeKflLsmOTEPkAxSVwB45LXvGfcLPpOWZ R0+8/DSOptExC0yBNAHKNrly8o/uXUTDUcSvabG6i2QO0xU/ZG6QUM+zkecVu+VpSjMm GCpHIGEi575+4QLW+m2ozqkQ7I/+hXByPM3L2/FMmcgMbR+X/zMkAnO4ulQ/2vCUndPc /R5APdkfBtKOJmHiR9ok6orNCaEOd5P2jY4GcubvkRjmALah5ZZ/gtjmYFAO2cIU/dMF 9o0O2XSglshld/xZg7WTTmb8lKCfx2icyUnO8RdNHaSpX9/QKVSe7yIVfi3lzVDRln7c xo0A== Received: by 10.52.67.226 with SMTP id q2mr15387561vdt.53.1338915061569; Tue, 05 Jun 2012 09:51:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 5 Jun 2012 09:50:21 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4AA3A95D6033ED488F8AE4E45F4744871D8B88E7@WABOTH9MSGUSR8B.ITServices.sbc.com> From: Eric Rescorla Date: Tue, 5 Jun 2012 09:50:21 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmFD0Mu5nsySXeU7zk9HWQUgFSjo0Y32OuEZGeUxNJIcWGRBAsEcwNbc5vwQU+RoGCFzwAW Subject: [rtcweb] Fwd: Review of draft-ietf-rtcweb-security-02 and draft-ietf-rtcweb-security-arch-01 documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 16:51:03 -0000 ---------- Forwarded message ---------- From: Eric Rescorla Date: Tue, Jun 5, 2012 at 9:35 AM Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-security-02 and draft-ietf-rtcweb-security-arch-01 documents To: "DRUTA, DAN" Dan, Thanks for your review, comments below. > I reviewed the latest version of the drafts and below are my comments/sug= gestions/corrections (not as comprehensive as Mark's). > In general I think the documents are well written with good references an= d paint a rather comprehensive picture of the issues to be addressed for rt= cweb. > > Draft-ietf-rtcweb-security-02 > > 1.Introduction - =A0second paragraph after the diagram: > "Each of their browsers exposes standardized JavaScript calling APIs whic= h are used by the Web server to set up a call between Alice and Bob." > > =A0This statement can be a bit more clear in that the APIs are executed > =A0locally (in the user agent) as java script downloaded from the Web > =A0Server. The next paragraph eludes to the fact that logic is > =A0controlled by the calling service but I think it will be important > =A0to distinguish between APIs implemented by the user-agent and > =A0APIs/functions implemented by the calling service. I added "implemented as browser built-ins". Hope this helps. > 4.1 Access to Local Devices. > Since this describes the threat I think is important to point out > the fact that even when the user provides consent it is difficult > for them to determine the real reason they give the consent to a > site. Take the scenario in which a site obtains consent from the > user for an app that captures a clip and saves it on the user's hard > drive. Later on, if the user gave permanent consent to the site, the > site can obtain access to the camera for the purpose of streaming > without the user knowing that. This can be confusing for users even > if they trust the site. Right. This is a good example of the gap between the policy the user wishes to have enforced (my information will be used only for purposes A and B and not purpose C) and what we can technically enforce (site X can have my data but they do whatever they want...) > 4.2 IP location Privacy > "Note that as soon as the callee sends their ICE candidates, the callee l= earns the callee's IP addresses." > This must be "the caller learns the callee's IP address" Good catch. Fixed. > 4.3.2.3. Third Party Identity > "It is possible (see[I-D.rescorla-rtcweb-generic-idp]) to use systems of = this type to authenticate RTCWEB calls, linking them to existing user notio= ns of > identity (e.g., Facebook adjacencies). Calls which are authenticated in t= his fashion are naturally resistant even to active MITM attack by the calli= ng site." > > Not to get too much into semantics, I think it is important to make > the distinction that users are authenticated (using whatever IdP) > and calls are authorized based on the assertions provided by the Idp > for the authenticated user. Good point. Added something. Let me know if you think it helps. > Draft-ietf-rtcweb-security-arch-01 > > 1.Introduction > "The Real-Time Communications on the Web (RTCWEB) working group is tasked= with standardizing protocols for real-time communications between Web brow= sers." > > While there's nothing inaccurate about the statement, I would like to mak= e it more generic because it is more than just communication between web br= owsers. In my opinion the WEB part in the acronym is all about using the we= b technologies to enable real time communications. > > A proposed edited definition would be "... standardization protocols > for enabling real-time communications within user-agents using web > technologies (e.g JavaScript)". That's an improvement. Accepted. > I have been trying to identify the appropriate section for a rather contr= oversial requirement: =A0Lawful Intercept. It is expected that service prov= iders for RTCWeb/WebRTC will be required to provide support to lawful inter= cept and I think we need to capture these requirements so we can map them t= o the security architecture. I think Martin's assessment of the situation here is pretty much right. -Ekr From ibc@aliax.net Tue Jun 5 10:31:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3E021F8744 for ; Tue, 5 Jun 2012 10:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuELAM7-dRjL for ; Tue, 5 Jun 2012 10:31:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3559821F86DA for ; Tue, 5 Jun 2012 10:31:15 -0700 (PDT) Received: by lagv3 with SMTP id v3so4363776lag.31 for ; Tue, 05 Jun 2012 10:31:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=1uDirY3VrHHT/HqhcyTQdCdyBWBB9mMD2wAnuAHO3+c=; b=dZlH1svVHiVkoaNIgDFbFspGWw5Y9FJmNuCdxjECx1UiAffnYYmaRVVA6ugt1xTTrD REm+7tx46VA7HbA8Yr+sBBEs1poABqTuqOjtnY8IRw5ENwSiatjA+7lAmZiygFigVKIz 5WdidZkS2rjDCFIVFCH0fVJ4CmgEA9H8Keg5JDmj5eXXBySDiH0h3vsCW0mFdm8lXFps UlXpHWuP7R4FZykRnXQXfo1R9EDPCPqDc7TkUZvQkQg2aZeXva02mWMCrkkUyWjvgi7I TRb+grWJhBuoVo24S2a26jkX+F1fatP7FsxcWSytTc3ZgibBP3qUlPDH1SMDhpY+uzAD fqmw== Received: by 10.112.85.225 with SMTP id k1mr8414762lbz.38.1338917474620; Tue, 05 Jun 2012 10:31:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.7.74 with HTTP; Tue, 5 Jun 2012 10:30:54 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 5 Jun 2012 19:30:54 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlB2e27XOsZbxTAIQ5yiK4TziVjBQymdu6V98gGuPmH3+WxDRAc4FpVq9rArKw84+1K+36f Subject: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 17:31:17 -0000 Hi, just wondering if there could be some "workaround" for this "issue": I've a VPN (Cisco vpnc) interface in my host. Using Chrome dev-channel and setting a public STUN server in my WebRTC application I've realized that during ICE stuf it also takes the VPN interface (which makes sense) but when it tries to contact the STUN server from the VPN interface it will have not response (due to VPN/network routes and so...) which causes a "STUN timeout" (~2-3 seconds). Of course this happens for *every* outgoing or incoming media session when the browser needs to create a SDP. I don't think there is a solution for this "issue", just wondering. Regards. --=20 I=C3=B1aki Baz Castillo From martin.thomson@gmail.com Tue Jun 5 10:53:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD97E21F8770 for ; Tue, 5 Jun 2012 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.175 X-Spam-Level: X-Spam-Status: No, score=-4.175 tagged_above=-999 required=5 tests=[AWL=-0.576, 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 OAApvByYVCOl for ; Tue, 5 Jun 2012 10:53:45 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3CE21F876E for ; Tue, 5 Jun 2012 10:53:41 -0700 (PDT) Received: by bkty8 with SMTP id y8so5638397bkt.31 for ; Tue, 05 Jun 2012 10:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SQDe0WoFqwtLJ/aaXCKHgthldOmVXe+9Aa95ihBF4cA=; b=haehyik3v/1w8jYvr7YuAMSGiA0qQmF765fkRLj49DIP7yakn+5OvYZxfMI3NkpQ3B P3BEe61td+gY+xdgvaGd0LSCRXByNYiUbES1QDNh28j0uqsBEuiHjvLGszBmRMR75obY wuP47az3hCxanfedUUlyP1h8BqH2hDKz8JajLO1r1Zy5kwN1hGTMczxahnIl0NdRzCl0 UBAWm0+yvzxf1Lm8BOQwJp9TUFuKBugEoHn07GaHr88coUNCe0ip9xAGiW/LpqtM7lg1 guB0zX9C5LjfryMQ+pbC0DLk62mnI2sH5EkhNqdf/2bYrJzyLcNZIN++Euw/V3wRAuLG Rm/g== MIME-Version: 1.0 Received: by 10.205.33.136 with SMTP id so8mr9691876bkb.1.1338918819820; Tue, 05 Jun 2012 10:53:39 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 5 Jun 2012 10:53:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 10:53:39 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: Review of security documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 17:53:47 -0000 Selective responses inline. On 5 June 2012 09:50, Eric Rescorla wrote: >> Therefore, it's easy to draw the implicit conclusions of the draft, >> namely: >> =C2=A01. a receipt consent mechanism like CORS is necessary, and >> =C2=A02. user consent for access to input devices is necessary _and_ >> =C2=A0 =C2=A0 sufficient...for this mode. > > I've tried to address this some more in Section 4.1. I like it. >> PRIVATE COMMUNICATIONS AND CONSENT >> >> The above assumes that the site has access to media. =C2=A0That is, >> permission for input devices is being granted to the site. =C2=A0However= , it >> is possible to imagine a mode of communications where the site mediates >> the creation of a secure channel, but does not have access to that >> channel. > > IMO there are actually two issues here: > > (1) consent > (2) peer authentication > > To give an example, I might be happy to have Gmail be able to > access my camera and microphone without a big consent experience, > but I still want to be able to have calls that I know Gmail > can't listen in on in. That way I can have easy calls, but > when I want security I can have it. I have tried to make this > clear in the new text. I think in your situation you want a separate type of consent - access to a specific "session". The idea of what a "session" entails probably needs better definition than this, but I'm sure you know what I mean. (I'd probably associate this with a single transport - and all streams that are attached to that transport, but you don't get to do that with the current API. More on that in future, I promise.) When you consent to granting the site access to input devices, that site can then record you. Presumably, the site also gets to record streams of remote origin without that consent. What you desire is something more than just consent to access a device, or peer authentication...it's a "hands off" signal from the user. As I've already said, tying the "hands off" signal into peer authentication is probably a sensible optimization. >> AUTHENTICATION MODELS >> [...]=C2=A0The site can offer an identical (or similar) certificate in >> the DTLS handshake as it did with the HTTPS TLS handshake. > > OK. I'll add something to the security-arch document. Where exactly? >> CALL MEDIATION AND REPUTATION > Hmm... my experience is that sites and ad networks don't do > that much vetting of JS, actually. I've done ad network > studies where we put arbitrary JS that does a pile of > XHR-type stuff in ads and nobody seemed to notice. I've seen a range of responses from sites. Some sites vet advertisers carefully, others could care less as long as the money flows. Those that vet have usually been stung once already. If reputation is important to you, then it is your responsibility to safeguard your own reputation. If you rely on others, then you can use technical measures (checking, etc...), or simply rely on their own desire to safeguard their reputation. In summary, I don't see a need for a specific technical solution to this problem. >> See thread on hiding IP addresses. =C2=A0In order to avoid tracking via = IP, >> clients should not use the Internet. =C2=A0I hear that Tor is somewhat h= andy >> at making it possible to have cake that you can eat too. =C2=A0That said= , I'm >> not sure that that particular cake tastes all that nice... > > I'm not sure either, but.... what are you looking for he? Section 5.4 stipulates requirements that I don't think are reasonable. Including discussion on the subject, including countermeasures, with a conclusion that there are no requirements on the API would be good. However, guidance for site implementers would be sensible. >> It might make sense to consider _all_ unsecured HTTP is being in the >> same origin for the purposes of this. > > I'm not sure what you are suggesting? Seems like a big error to > treat http://www.foo.com/ and http://www.bar.com/ as the same > for consent purposes. Sorry, that was too abstract to be actionable. You already established that - in the presence of a network attacker - consent to foo.com is equivalent to consent to bar.net. Therefore, it seems reasonable to regard the two as being equivalent. Once you make that leap, then it is easy to see that you don't have enough granularity to make any consent meaningful. So you have to conclude that providing a (persistent) consent for non-HTTPS sites is pointless. >> UNLINKABILITY >> >> security-arch@S5.5 >> >> Nothing on this in the security doc. =C2=A0What is the goal here? > > I'm not sure I understand the question. I want to be able > to make calls to people without having them linked? What about identity? While you are in the business of creating an identity system, wouldn't it be nice if the site you are using couldn't identify the people using that site? Imagine that you are able to create an assertion that you are dhouhqed08gslkn209eejit8sfsdo@rtfm.com (that well known IdP), which is translated (by the IdP validator) to a ekr@rtfm.com only in the browser chrome... From martin.thomson@gmail.com Tue Jun 5 11:19:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2835321F87B2 for ; Tue, 5 Jun 2012 11:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.984 X-Spam-Level: X-Spam-Status: No, score=-3.984 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcAPNc9OVHxh for ; Tue, 5 Jun 2012 11:19:03 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6856E21F87A8 for ; Tue, 5 Jun 2012 11:19:03 -0700 (PDT) Received: by bkty8 with SMTP id y8so5661107bkt.31 for ; Tue, 05 Jun 2012 11:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IRHd58tLApRellJ3BGeNZfSIT1v/YVU2RL+x/XTlV6E=; b=FB98Xdh2ssesyaLuktVapYy8Jg4vLWzvfmk434krJ07PRAnZO7i5HiXOVMFj2636kV o+ZnR3w5brafTjOmit1wcT49Bfq+cLNIraCgP5waGUevZ71pDnZUe8h4CqZc0jIc7U/t ZU9yX50srJqbamgK8btyx71CRqSPjVhF4SBP4dGZ63n0WDBMRnT0+LmVqi8g9D1NSeUq TjGNPx9s2arPHm4aBlMEpJEPgDEycFCuK7dO5LAM/el0hHPavOg79Syw9r1jYVTf2/7O +bRkfWG03wRZr1ePr1rsDNYEPG2KugJEDqfnia/Q0bfQlfkOY5V/BkdDbIW2XCzPdt7C v3jg== MIME-Version: 1.0 Received: by 10.204.150.84 with SMTP id x20mr9880713bkv.26.1338920342432; Tue, 05 Jun 2012 11:19:02 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 5 Jun 2012 11:19:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 11:19:02 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 18:19:04 -0000 On 5 June 2012 10:30, I=C3=B1aki Baz Castillo wrote: > [...] but when it tries to contact the STUN server from the VPN > interface it will have not response (due to VPN/network routes and > so...) which causes a "STUN timeout" (~2-3 seconds). Of course this > happens for *every* outgoing or incoming media session when the > browser needs to create a SDP. > > I don't think there is a solution for this "issue", just wondering. It's not an issue. Some candidate pairs are always going to fail. That shouldn't block the testing (and nomination) of other pairs. If the ICE implementation struggles or lags as a result, then that's a fault in the implementation. From juberti@google.com Tue Jun 5 12:30:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD96F21F85A4 for ; Tue, 5 Jun 2012 12:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 CANfWbx3t5Qa for ; Tue, 5 Jun 2012 12:30:46 -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 576FB21F84D8 for ; Tue, 5 Jun 2012 12:30:45 -0700 (PDT) Received: by qabj40 with SMTP id j40so2968235qab.15 for ; Tue, 05 Jun 2012 12:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=/jQ1jUYUOHbZIROK203Jf5w0y6R9h4d/CwsjboIVEss=; b=p4uQOo7eh5cSsDHk5SsUjz2QtOHWAx5c5HR3cljoQnz9kun8ljBNlLAMHnAica4zxb yq3ZsPfOYttd338VjYygcGj+7z+cfuQg/mgGKmgDTJZHZkpwXA5gXIeICzyMuI0KDrHB W3x3Kmp+oJ+whjHKn8RXGXxoObFGAexUw4/s7MyHBwedZWGnntvHYxZ3GqaNOo4QEtHH u4j4SSQTjTtlJVH1zyZNztyDV32Ly5MFkWP0dOJx4YyRAzaTrGAbOXD9QzbAeNsFguNH cNgS6imPL1APg5Wkymi7e2/Dz9Bs2JY+eQ4o0UCEWCdqSB1TsnuN1zSpmfm/LCH6yjyz LPig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=/jQ1jUYUOHbZIROK203Jf5w0y6R9h4d/CwsjboIVEss=; b=d7II0icLiFYHMD8AVgkgz0MZ6KjQ57BJpu+vyGWDp1r1TfYYyV2QkMiFPcD1AW+Pua Mb2335SOGP41bxONaQqWW6RJYwDfQuYqIGRNDmZGLnsBXmLv4Il4jrJ7tSVa5CJJFkBl rbrf5ovQrOM3xvpfZQcY49/A9u6AKYWIZAIqj6AsGCNPIoyGtryEfJDXgtyR0AoXEiQn wmQaOquHLhiB79+wfU6EQ+5acibv1WTgOmqpC4jWY52gnMpZP+twqM93y+fPO99iglQF +022D4laWss70E2J1qgF9eXDYue0yyakluei3CxFJv5FjkLfhCWdQWWPKCjI1oV6xj1S UbMg== Received: by 10.224.189.19 with SMTP id dc19mr18323583qab.76.1338924644459; Tue, 05 Jun 2012 12:30:44 -0700 (PDT) Received: by 10.224.189.19 with SMTP id dc19mr18323575qab.76.1338924644367; Tue, 05 Jun 2012 12:30:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.211 with HTTP; Tue, 5 Jun 2012 12:30:24 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 5 Jun 2012 15:30:24 -0400 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf3033464dcefbce04c1beafb4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlVKUSp+JAv7ZBJcLgoVPilGERzHXzlA7emiZdhKBI2jypyFRFeWFmCT3HWrldgQtxoG42dtHCUZt4uVNjEShBYbpGCzrZWcEIvMzYiAmDkkky3U1Erlg/Ut8oXShZVI1KJ8bSV Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 19:30:46 -0000 --20cf3033464dcefbce04c1beafb4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 5, 2012 at 2:19 PM, Martin Thomson wr= ote: > On 5 June 2012 10:30, I=C3=B1aki Baz Castillo wrote: > > [...] but when it tries to contact the STUN server from the VPN > > interface it will have not response (due to VPN/network routes and > > so...) which causes a "STUN timeout" (~2-3 seconds). Of course this > > happens for *every* outgoing or incoming media session when the > > browser needs to create a SDP. > > > > I don't think there is a solution for this "issue", just wondering. > > It's not an issue. Some candidate pairs are always going to fail. > That shouldn't block the testing (and nomination) of other pairs. If > the ICE implementation struggles or lags as a result, then that's a fault in the implementation. > If you don't have trickle candidates, you can't send the offer until you have gotten all candidates, or given up on the ones that haven't responded yet. --20cf3033464dcefbce04c1beafb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 5, 2012 at 2:19 PM, Martin T= homson <martin.thomson@gmail.com> wrote:
On 5 June 2012 10:30, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
> [...] but when it tries to contact the STUN server from the VPN
> interface it will have not response (due to VPN/netw= ork routes and
> so...) which causes a "STUN timeout" (~2-3 seconds). Of cour= se this
> happens for *every* outgoing or incoming media session when the
> browser needs to create a SDP.
>
> I don't think there is a solution for this "issue", just= wondering.

It's not an issue. =C2=A0Some candidate pairs are always going to= fail.
That shouldn't block the testing (and nomination) of other pairs. =C2= =A0If
the ICE implementation struggles or lags as a result, then that's a=C2= =A0
fault in the implementation.=

If you don't have trickle candidates, you can't= send the offer until you have gotten all candidates, or given up on the on= es that haven't responded yet.=C2=A0
--20cf3033464dcefbce04c1beafb4-- From martin.thomson@gmail.com Tue Jun 5 12:57:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB11021F87CF for ; Tue, 5 Jun 2012 12:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.058 X-Spam-Level: X-Spam-Status: No, score=-4.058 tagged_above=-999 required=5 tests=[AWL=-0.459, 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 wCLSk7UXzJHt for ; Tue, 5 Jun 2012 12:57:33 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27DC421F87CD for ; Tue, 5 Jun 2012 12:57:32 -0700 (PDT) Received: by bkty8 with SMTP id y8so5750660bkt.31 for ; Tue, 05 Jun 2012 12:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LA4dZ+jOapOcjHT4csxd/fHFPdQ7loOWou+6SQ72TZQ=; b=Orgdy5JgY28l8sQYwDsulEX6HCYszZX+pWbEyScvBltsHsXrfyfiq2oy6VbHcRKQnf RvRKKtTXmGPEBWNQVJpvPZMT8O2e1BeX/PnM1FK/gKxRgbHAmWMB4O5cDXq9RhQzPmme 6fIn5fDX0LUosscR3um2F+6bOCTAO5vYHHCyHvBY7fTyFjP15unUGegv0skmpY69fL+2 OyuCf2kXbsDUUMwroUu20jNEfXUYvcDv23u347z9Xd0fcSwAdWJhiQiDMgYJ75a1nMjQ 4GuYz/F5HxgBoGsU/bUA1YIgzyFbqSeHZwlGI2d023BrwR24nfd0PR27iEtrAqGvVvg/ utdA== MIME-Version: 1.0 Received: by 10.205.119.12 with SMTP id fs12mr10174781bkc.49.1338926251983; Tue, 05 Jun 2012 12:57:31 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 5 Jun 2012 12:57:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 12:57:31 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 19:57:34 -0000 On 5 June 2012 12:30, Justin Uberti wrote: > If you don't have trickle candidates, you can't send the offer until you > have gotten all candidates, or given up on the ones that haven't responded > yet. Right. If you want to collect a server reflexive address for every host candidate before moving on to other things, then you end up waiting for a fairly substantial period of time. There is no reason to gate media negotiation on transport setup. Trickle candidates is basically a way of saying that you need this separation. From internet-drafts@ietf.org Tue Jun 5 13:48:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C021F87FB; Tue, 5 Jun 2012 13:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, 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 oWmAN45DKYUo; Tue, 5 Jun 2012 13:48:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903D021F87F1; Tue, 5 Jun 2012 13:48:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120605204802.10262.39800.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2012 13:48:02 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 20:48:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Javascript Session Establishment Protocol Author(s) : Justin Uberti Cullen Jennings Filename : draft-ietf-rtcweb-jsep-01.txt Pages : 31 Date : 2012-06-05 This document proposes a mechanism for allowing a Javascript application to fully control the signaling plane of a multimedia session, and discusses how this would work with existing signaling protocols. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ From ibc@aliax.net Tue Jun 5 14:41:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E7421F8746 for ; Tue, 5 Jun 2012 14:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CSZKTbOWggF for ; Tue, 5 Jun 2012 14:41:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B825E21F873E for ; Tue, 5 Jun 2012 14:41:49 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4672327lbb.31 for ; Tue, 05 Jun 2012 14:41:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=wJnrtZGlFuRVEl9FC3kXsXrvalu4EPcTNs9UPxrzU6Q=; b=hcGliZkNyYAu4a4rBS/+Iowu/NbP+k4Ufcj/1bfsLTu1Kta9oyvL11K1hC7CxtFPPL XtxTpugk3OwnDzOW8vSaS5leEj+fBHx4N4++aSAT2gwiBJALoE63SqWYmF5RtWEyfwim RwCYtzYG7sTMqCykJBDkRfi562cgmEiaPm3TBrLi0pFRbywzdnp4rr0HRKFFx29xCzlm ZCIcvYuGqMAbCY5KAxiqqkWlprXeMJBgWH7P7YONbYdqzeIhfXBBrtov6Y4Sk+vWUIvz 32pyRsmkFFRFPMBUyvvjI7a9BmzebVr+5DFoXlgej5XyRPiGWIs+sOkVg0EujZxuvnzG m+BA== Received: by 10.112.49.230 with SMTP id x6mr8901745lbn.86.1338932508688; Tue, 05 Jun 2012 14:41:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.7.74 with HTTP; Tue, 5 Jun 2012 14:41:28 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 5 Jun 2012 23:41:28 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmlXv3HdTiRjN/M4Q4NZSauhYXTLdrrN+cYg3p+XnzE8iDoIkC2llH+Nl5gwK0mgdAojrKG Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 21:41:50 -0000 2012/6/5 Martin Thomson : > It's not an issue. =C2=A0Some candidate pairs are always going to fail. > That shouldn't block the testing (and nomination) of other pairs. Perhaps I didn't explaing properly. What I mean is that when the browser sends the STUN UDP request from the VPN interface, it will NOT receive a UDP response in that interface. So this is the worst case: timeout in receiving a STUN response. --=20 I=C3=B1aki Baz Castillo From martin.thomson@gmail.com Tue Jun 5 14:50:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F331121F87F1 for ; Tue, 5 Jun 2012 14:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.823 X-Spam-Level: X-Spam-Status: No, score=-3.823 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OcbGPf95tp3 for ; Tue, 5 Jun 2012 14:50:44 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1968421F87E1 for ; Tue, 5 Jun 2012 14:50:36 -0700 (PDT) Received: by bkty8 with SMTP id y8so5842560bkt.31 for ; Tue, 05 Jun 2012 14:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MRICl1MQARRsBv3GB9rV/V2ZZaw2rocZZVG4zx0T8tw=; b=0XHhbk3A/+UXQ+/ec+hcjm539qW2fvz+zjmGmzK4BbScxNxxzFIFZhVGmrWIC2f5lu JYR1p4BUh/eVpvKc4YhdAiDiBCRq4DhKlmAo6yJ/BA06IRNB6tAJFWAW9Y5ARLIs9IGH wQ2nQa1K65PjyiZxP3xZfKdXagFgtxsQHj/t9oBH31icbxxCpXE4YCO0XH/Cb6okQgga 3JTVfFfvnxiEIxQoUcogL3C+jhb+rB4lFjXsjg+xsfRSN5srZM7EDsZDFIGzCwj+nfxz wJlyxE+YTQmI8IGss8HTMMzCjVPeYBbA5L/5awrG1m1ReDIcCarSBc3ep8r/vew19thT d4pg== MIME-Version: 1.0 Received: by 10.204.128.149 with SMTP id k21mr10244656bks.42.1338933036163; Tue, 05 Jun 2012 14:50:36 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 5 Jun 2012 14:50:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 14:50:36 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 21:50:45 -0000 On 5 June 2012 14:41, I=C3=B1aki Baz Castillo wrote: > 2012/6/5 Martin Thomson : >> It's not an issue. =C2=A0Some candidate pairs are always going to fail. >> That shouldn't block the testing (and nomination) of other pairs. > > Perhaps I didn't explaing properly. What I mean is that when the > browser sends the STUN UDP request from the VPN interface, it will NOT > receive a UDP response in that interface. So this is the worst case: > timeout in receiving a STUN response. No misunderstanding. That's expected behaviour. And it's not specific to interfaces that can't reach the specified address. Some UDP packets just don't make it. (Though in this case, there are several sent, so the odds of all of them getting lost is astronomically low.) From ibc@aliax.net Tue Jun 5 16:41:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2328E21F871A for ; Tue, 5 Jun 2012 16:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGJomqhUzRIi for ; Tue, 5 Jun 2012 16:41:39 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAD421F8713 for ; Tue, 5 Jun 2012 16:41:38 -0700 (PDT) Received: by lagv3 with SMTP id v3so4596776lag.31 for ; Tue, 05 Jun 2012 16:41:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=kS7WHuzr3VxCUeeAJUbMKqu1mgkJSYHPNEDjESc7Lew=; b=W1H96py65zD0lYcZ3wbH2YTvUlohBE4O8f53hye8bceUlwhzFRBClyMm4n4Jll5H38 ViOUt/7wULysFhUvnYehnEwS7JAzSIGrSHj22SqpCg7CbNalvadZYSSxznc1Z7fEGBo1 Eo7dLtm1+csE2PLh+AIj8jP8JWBaHezXqg/+E3opnvb5hJMSxcuROB69BGs5xSreTNXI uHaIYWhB17eeK8L4/9AapTilktN8G2mrsv9ov7cQei5V6OKS3yISfKVax9XfCVoOuk39 aKHH2+keCemGXWy8EYuMjcM7my24iNYL/m9/RpNZRG6AgfR+amM6iUudML7terxScGvv rvMQ== Received: by 10.112.42.228 with SMTP id r4mr8748588lbl.4.1338939697914; Tue, 05 Jun 2012 16:41:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Tue, 5 Jun 2012 16:41:17 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 6 Jun 2012 01:41:17 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkCwgEe5GF3cyzgW8y/7kZEjIx2OkOsIzox/hJQ8GhjwJ/9lBnjw3NmxUe44Mbbb2lBPn7S Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 23:41:40 -0000 2012/6/5 Martin Thomson : > No misunderstanding. =C2=A0That's expected behaviour. =C2=A0And it's not > specific to interfaces that can't reach the specified address. =C2=A0Some > UDP packets just don't make it. =C2=A0(Though in this case, there are > several sent, so the odds of all of them getting lost is > astronomically low.) I hope there will be some way to try ICE candidates in all the networks addresses/interfaces and, later once we have learned which interfaces "work", then use just them for ICE/STUN discovery. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Wed Jun 6 01:03:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206E821F85B8 for ; Wed, 6 Jun 2012 01:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 kNvVg6CMy8Jj for ; Wed, 6 Jun 2012 01:03:03 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BF3D321F85B5 for ; Wed, 6 Jun 2012 01:02:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E4FD39E13F for ; Wed, 6 Jun 2012 10:02:58 +0200 (CEST) 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 OGtcKncUpChu for ; Wed, 6 Jun 2012 10:02:57 +0200 (CEST) Received: from [172.28.92.110] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 30E4739E12F for ; Wed, 6 Jun 2012 10:02:56 +0200 (CEST) Message-ID: <4FCF0EAC.3040900@alvestrand.no> Date: Wed, 06 Jun 2012 10:02:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 08:03:04 -0000 On 06/06/2012 01:41 AM, Iñaki Baz Castillo wrote: > 2012/6/5 Martin Thomson: >> No misunderstanding. That's expected behaviour. And it's not >> specific to interfaces that can't reach the specified address. Some >> UDP packets just don't make it. (Though in this case, there are >> several sent, so the odds of all of them getting lost is >> astronomically low.) > I hope there will be some way to try ICE candidates in all the > networks addresses/interfaces and, later once we have learned which > interfaces "work", then use just them for ICE/STUN discovery. > That's what ICE/STUN discovery is for.... and once you yank out your cable or reconnect your wireless, it all changes anyway, so caching has very limited value. Better to program apps in such a way that you can live with interfaces that don't answer. From harald@alvestrand.no Wed Jun 6 04:51:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C82D21F86AD for ; Wed, 6 Jun 2012 04:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 GbFOMzSTo2Iu for ; Wed, 6 Jun 2012 04:51:45 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 82E0E21F869C for ; Wed, 6 Jun 2012 04:51:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F52C39E154; Wed, 6 Jun 2012 13:51:42 +0200 (CEST) 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 Ky3ftXcQudWK; Wed, 6 Jun 2012 13:51:41 +0200 (CEST) Received: from [172.28.92.110] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CFA5639E098; Wed, 6 Jun 2012 13:51:39 +0200 (CEST) Message-ID: <4FCF4446.6030003@alvestrand.no> Date: Wed, 06 Jun 2012 13:51:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Colin Perkins References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCD0198.2040307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC11.7010304@alvestrand.no> <94DB3F99-8C0C-4B8D-8BB5-AB833AB89FE0@csperkins.org> In-Reply-To: <94DB3F99-8C0C-4B8D-8BB5-AB833AB89FE0@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 11:51:50 -0000 X-List-Received-Date: Wed, 06 Jun 2012 11:51:50 -0000 On 06/05/2012 03:18 PM, Colin Perkins wrote: > On 5 Jun 2012, at 07:49, Harald Alvestrand wrote: >> On 06/04/2012 10:03 PM, Ejzak, Richard P (Richard) wrote: > ... >>> Even though RTP packets with different payload types could potentially reuse the same SSRC value, SSRC values cannot be independently assigned per m line with the current BUNDLE scheme since RTCP packets can be identified only using SSRC values (payload type is not a field in RTCP packets). So the bundled m lines have to share a single SSRC space, thus increasing the likelihood of SSRC collision >> Yes. At 302 SSRCs in the same RTP session the chance of a collision is 50%. Applications that don't handle SSRC collisions are broken. > I agree that applications that don't handle SSRC collisions are broken, but RFC 3550 Section 8.1 gives a vastly lower probability of collision. Is there a mistake in the calculation in the RFC? > Yes, the RFC is completely wrong. Quote 1: If N is the number of sources and L the length of the identifier (here, 32 bits), the probability that two sources independently pick the same value can be approximated for large N [26] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is roughly 10**-4. I don't have the book quoted, so I can't say where it's picked from. I suspect that this may be the probability that for any given two sources, they'll pick the same value, but I can't reverse engineer this. Quote 2: Again, if N is the number of sources and L the length of the identifier, the probability of collision is N / 2**L. For N=1000, the probability is roughly 2*10**-7. This is the probability that a collision will occur when one adds SSRC number N+1 to the session that already contains N SSRCs that have been added without collision. The exact formula for the chance that *any* collision happens will be the birthday paradox formula, which is easy to derive from the one above. From tterriberry@mozilla.com Wed Jun 6 07:28:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB6B21F8896 for ; Wed, 6 Jun 2012 07:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4ETZOlg0Qs8 for ; Wed, 6 Jun 2012 07:28:00 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 157C021F8892 for ; Wed, 6 Jun 2012 07:27:59 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 55524F21F4 for ; Wed, 6 Jun 2012 07:27:59 -0700 (PDT) Message-ID: <4FCF68EE.3090708@mozilla.com> Date: Wed, 06 Jun 2012 07:27:58 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCD0198.2040307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC11.7010304@alvestrand.no> <94DB3F99-8C0C-4B8D-8BB5-AB833AB89FE0@csperkins.org> <4FCF4446.6030003@alvestrand.no> In-Reply-To: <4FCF4446.6030003@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:28:00 -0000 Harald Alvestrand wrote: > The exact formula for the chance that *any* collision happens will be > the birthday paradox formula, which is easy to derive from the one above. This is what I thought, too, but that just makes your 50% number more confusing. Plugging 302 and 4294967296 into http://jeff.aaron.ca/cgi-bin/birthday gives me 0.001%, not 50% (I got the same value when I worked it out myself). But one out of a thousand is still a not-insignificant number. The approximation in your Quote 1 is actually pretty close, but _higher_ than the real value (by 0.3% of the real value, or 0.001058% (actual) vs. 0.001062% (approximate). From tterriberry@mozilla.com Wed Jun 6 07:38:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189E621F8760 for ; Wed, 6 Jun 2012 07:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfnPV-JlrFF0 for ; Wed, 6 Jun 2012 07:38:56 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 81E1E21F86B2 for ; Wed, 6 Jun 2012 07:38:56 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 42473F267D for ; Wed, 6 Jun 2012 07:38:56 -0700 (PDT) Message-ID: <4FCF6B7F.1060102@mozilla.com> Date: Wed, 06 Jun 2012 07:38:55 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCD0198.2040307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC11.7010304@alvestrand.no> <94DB3F99-8C0C-4B8D-8BB5-AB833AB89FE0@csperkins.org> <4FCF4446.6030003@alvestrand.no> <4FCF68EE.3090708@mozilla.com> In-Reply-To: <4FCF68EE.3090708@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:38:57 -0000 Timothy B. Terriberry wrote: > Harald Alvestrand wrote: >> The exact formula for the chance that *any* collision happens will be >> the birthday paradox formula, which is easy to derive from the one above. > > This is what I thought, too, but that just makes your 50% number more > confusing. Plugging 302 and 4294967296 into Also, if I'm working this out correctly, you cross the 50% threshold at 6563 SSRCs instead of 302. From ibc@aliax.net Wed Jun 6 11:55:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B82E21F85F0 for ; Wed, 6 Jun 2012 11:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9oKJEuZBaES for ; Wed, 6 Jun 2012 11:55:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5538921F85F2 for ; Wed, 6 Jun 2012 11:55:13 -0700 (PDT) Received: by lagv3 with SMTP id v3so5387715lag.31 for ; Wed, 06 Jun 2012 11:55:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=rMxRT2GwBKoiOftyii2Izpn4iPkmC9CHovkBDScW3P8=; b=GK8+zGd7MemD77FdkL/043LC94A84PzUzFlvrA/PP7UKy44dUrHOlkAcWhVQQSeQRN tuKgKqzTXfLC3LtxY7n8A8o5j5OrtnoU5oypHTAviWYXDcaG4jqD8/d5nFm660iYnxUi 1/qPNbUHeTEAnyOO0tYHEG3Qqp1a1Bw8zw+smZKQuoSIEXDLFM3Ihcp2BcF8pv/CBvNH Y0la/GyRIMUsl/1JbsqxyhLsJyQxcDbF1yYodFxX3JU9h2MOclzWexluSjVJnqtw+Agf dwVSFO7kQKcJ1B4GuqBJF2CDNpj+/daxH5JXF2D3OmUkTK30ZBJq1ka4Lgiv3KQaAGnX dE3g== Received: by 10.152.135.105 with SMTP id pr9mr22888000lab.37.1339008912207; Wed, 06 Jun 2012 11:55:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Wed, 6 Jun 2012 11:54:52 -0700 (PDT) In-Reply-To: <4FCF0EAC.3040900@alvestrand.no> References: <4FCF0EAC.3040900@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 6 Jun 2012 20:54:52 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmH5gAzC0bXPdtPAk3WfooDJkLDjRHH5JlHTdFew//Utr5POHi6Vg883evVfxzMr6bUg7Bb Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 18:55:14 -0000 2012/6/6 Harald Alvestrand : > That's what ICE/STUN discovery is for.... and once you yank out your cabl= e > or reconnect your wireless, it all changes anyway, so caching has very > limited value. Sure, but in my case it means ~3 seconds of delay for every WebRTC session. Just wondering: it would be "nice" if the SO would notify the browser when some change in the network settings happen, so the browser would then invalidate its cache and try again all the interfaces, and not just those that worked in the previous session. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Wed Jun 6 13:04:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7371421F87D1 for ; Wed, 6 Jun 2012 13:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 LkVBZRW+vNhb for ; Wed, 6 Jun 2012 13:04:19 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5832A21F87D0 for ; Wed, 6 Jun 2012 13:04:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE09339E166; Wed, 6 Jun 2012 22:04:20 +0200 (CEST) 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 t8T2+OnMjLHY; Wed, 6 Jun 2012 22:04:19 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D673E39E098; Wed, 6 Jun 2012 22:04:19 +0200 (CEST) Message-ID: <4FCFB7C0.9060503@alvestrand.no> Date: Wed, 06 Jun 2012 22:04:16 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <03FBA798AC24E3498B74F47FD082A92FC303@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCD0198.2040307@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92FC55A@US70UWXCHMBA05.zam.alcatel-lucent.com> <4FCDAC11.7010304@alvestrand.no> <94DB3F99-8C0C-4B8D-8BB5-AB833AB89FE0@csperkins.org> <4FCF4446.6030003@alvestrand.no> <4FCF68EE.3090708@mozilla.com> In-Reply-To: <4FCF68EE.3090708@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft on media multiplexing submitted to AVTCORE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:04:20 -0000 On 06/06/2012 04:27 PM, Timothy B. Terriberry wrote: > Harald Alvestrand wrote: >> The exact formula for the chance that *any* collision happens will be >> the birthday paradox formula, which is easy to derive from the one >> above. > > This is what I thought, too, but that just makes your 50% number more > confusing. Plugging 302 and 4294967296 into > http://jeff.aaron.ca/cgi-bin/birthday gives me 0.001%, not 50% (I got the Argh. That's 4G. I was using 64K. Somehow I'd lost half the SSRC. Explains the difference. My apologies. I'll crawl under a rock now. > same value when I worked it out myself). But one out of a thousand is > still a not-insignificant number. The approximation in your Quote 1 is > actually pretty close, but _higher_ than the real value (by 0.3% of > the real value, or 0.001058% (actual) vs. 0.001062% (approximate). > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From g.kiranreddy4u@gmail.com Wed Jun 6 22:09:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D6A11E810A for ; Wed, 6 Jun 2012 22:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCbx6cjE8RjG for ; Wed, 6 Jun 2012 22:09:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29C5211E8108 for ; Wed, 6 Jun 2012 22:09:15 -0700 (PDT) Received: by yenq13 with SMTP id q13so150819yen.31 for ; Wed, 06 Jun 2012 22:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=2yBBsiQ+MBbs7rqzsa98MpZme6vs+OGcGd3v9hj9b/E=; b=s/blBeSxjKG2QlcZsYQzLB/PDy2LUAI3kjbE6abx+QsnLMGM3osGtZEnB5cIL0CHoj u8ysFq5WiH/T/FnX/bHBsv/oHMeE0o9FvKIFMfM8iL30zx3TBFm5rGB5NHEBriI+PiT2 DPB2Yi7H5jQ2G2hGIe4Hci6FHF+8Uw8F6DQ5UxzcYxvJHyJjYZNieGJKyciypz33EoaO +G7HOK+f332h6NzOosmQNnzH9e9uO0c0QySb8yrc1ZEn+m0RLBbjR/6cxnW/cjf5dY0V qBqdDFec/MmTCsO8eH+g+FFcQUFJD8JLLisGCir8lOd3/oShLe+oShkx8PdGpd8AxEAB 2fVA== Received: by 10.42.157.136 with SMTP id d8mr334077icx.37.1339045754590; Wed, 06 Jun 2012 22:09:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.135.5 with HTTP; Wed, 6 Jun 2012 22:08:54 -0700 (PDT) From: kiran kumar Date: Thu, 7 Jun 2012 10:38:54 +0530 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=90e6ba1efe1a8a57d904c1dae235 Subject: [rtcweb] Query regarding mandatory filed names for JSON object. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 05:09:16 -0000 --90e6ba1efe1a8a57d904c1dae235 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I am new to this mailing list. In draft-sipdoc-rtcweb-open-wire-protocol-00 section 4, for the mandatory call control section, few fiel names were specified. Can any one please tell me, in which specification all these filed names are defined. Ans also possibility for adding new field names. Thanks, Kiran. --90e6ba1efe1a8a57d904c1dae235 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,
=A0
I am new to this mailing list.
In draft-sipdoc-rtcweb-= open-wire-protocol-00 section 4, for the mandatory call control section, fe= w fiel names were specified.
Can any one please tell me, in which specif= ication all these filed names are defined.
Ans also possibility for adding new field names.
=A0
Thanks,
Kiran= . --90e6ba1efe1a8a57d904c1dae235-- From tim@phonefromhere.com Thu Jun 7 02:42:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6675221F87A0 for ; Thu, 7 Jun 2012 02:42:47 -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, MIME_8BIT_HEADER=0.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 vTGnhH3rOTy9 for ; Thu, 7 Jun 2012 02:42:47 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7DF21F865B for ; Thu, 7 Jun 2012 02:42:46 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id E7B8937A905; Thu, 7 Jun 2012 10:51:47 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: Date: Thu, 7 Jun 2012 10:42:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FCF0EAC.3040900@alvestrand.no> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 09:42:47 -0000 On 6 Jun 2012, at 19:54, I=F1aki Baz Castillo wrote: > 2012/6/6 Harald Alvestrand : >> That's what ICE/STUN discovery is for.... and once you yank out your = cable >> or reconnect your wireless, it all changes anyway, so caching has = very >> limited value. >=20 > Sure, but in my case it means ~3 seconds of delay for every WebRTC > session. Just wondering: it would be "nice" if the SO would notify the > browser when some change in the network settings happen, so the > browser would then invalidate its cache and try again all the > interfaces, and not just those that worked in the previous session. Strikes me that you can get close to that with the current API.=20 In your candidate callback, you wait untill you see what you used = last-time and use it,=20 then if that fails you have to do a re-invite with the stuff that = trickled in later. (and update the cache). You are still at the mercy of any upstream network changes (e.g. = rotating=20 pools of public IPs - mifi switching roaming providers etc) that make = your cache=20 meaningless. T. >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Thu Jun 7 03:02:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5532021F876F for ; Thu, 7 Jun 2012 03:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVD89txlNWrD for ; Thu, 7 Jun 2012 03:02:15 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 669EE21F876C for ; Thu, 7 Jun 2012 03:02:15 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so491555lbb.31 for ; Thu, 07 Jun 2012 03:02:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=aG02HxnWv1tYC9JpUKkiQ/KGsCWur21HdXtcjSXNNX8=; b=CogXKKDLWULmG9rgzyO5orIQxTP8E8LG2kPYFdecqr+7zM00RhvWTij0EpAt3OgYu2 cddC8Te15S+En9A45pFyA4qx0YQfNUdPUhblzEc/lZ0mwBEmWgvGghTDx4p7edPcp27V PJn7sshIm/blSO54/MHn3BhCFv5sTjaoQssw44IteWc6t0S4Pu9HxMFkDSQnAodpv6QQ VdPpCeCeFniZyLHyJpIklUOnI4NZmLebief4C7qYvGDMBkRr7W6ss/QNJSOEGku4OCuA jVUHaIJ4AIocmcd17fRIypAGD3URBy32+B87U576gtIeareD6McaiuzBaG8R2uc9FJvv mJjg== Received: by 10.152.147.33 with SMTP id th1mr1835424lab.9.1339063334342; Thu, 07 Jun 2012 03:02:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Thu, 7 Jun 2012 03:01:54 -0700 (PDT) In-Reply-To: References: <4FCF0EAC.3040900@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 7 Jun 2012 12:01:54 +0200 Message-ID: To: Tim Panton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlJioiQmfz/2yWBXbEkSl64lLUgQn45wvdOeukLZxKC3V3FwmZ/qzQ457hcHCZ9WLsyORmp Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 10:02:16 -0000 2012/6/7 Tim Panton : > > On 6 Jun 2012, at 19:54, I=C3=B1aki Baz Castillo wrote: >> Sure, but in my case it means ~3 seconds of delay for every WebRTC >> session. Just wondering: it would be "nice" if the SO would notify the >> browser when some change in the network settings happen, so the >> browser would then invalidate its cache and try again all the >> interfaces, and not just those that worked in the previous session. > Strikes me that you can get close to that with the current API. > In your candidate callback, you =C2=A0wait untill you see what you used l= ast-time and use it, > then if that fails you have to do a re-invite with the stuff that trickle= d in later. > (and update the cache). It seems suitable :) --=20 I=C3=B1aki Baz Castillo From magnus.westerlund@ericsson.com Thu Jun 7 05:02:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F7B21F87E7 for ; Thu, 7 Jun 2012 05:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.146 X-Spam-Level: X-Spam-Status: No, score=-106.146 tagged_above=-999 required=5 tests=[AWL=0.103, 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 hjDsenUQn0La for ; Thu, 7 Jun 2012 05:02:56 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D6A1121F86D5 for ; Thu, 7 Jun 2012 05:02:54 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-85-4fd0986d8dae Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AE.6F.00702.D6890DF4; Thu, 7 Jun 2012 14:02:53 +0200 (CEST) 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.264.0; Thu, 7 Jun 2012 14:02:52 +0200 Message-ID: <4FD09869.6010205@ericsson.com> Date: Thu, 7 Jun 2012 14:02:49 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.2 Content-Type: multipart/mixed; boundary="------------030309080908010900030009" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+JvrW7ujAv+BtsWGVqs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujG2f+lgLNt5ir3hwfz5TA+P2vexdjJwcEgImEv/WPISyxSQu 3FvP1sXIxSEkcIpR4urihUwQzjJGiVMb3rCCVPEKaEt8mbCADcRmEVCReNl0ByzOJmAhcfNH I1hcVCBY4sWeK1D1ghInZz5hAbFFBNQlLj+8ALZNWEBP4uPfOcwQmyUl7rWvBurl4GAWCJDY v0MbJCwEtKqhqYN1AiPfLCSTZiFUgYSZgQZNudrCCGHLSzRvnc0MYRtKrF3wgRXCVpSY0v2Q HcK2kZi5vZ9pASP7Kkbh3MTMnPRyc73Uoszk4uL8PL3i1E2MwIA9uOW3wQ7GTffFDjFKc7Ao ifPqqe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDIfSVcemvNRDXh9ri7Dx3SGjZ9cIll cc7cYamrtuuV/1/eUIG/1+tO2LO0Fz35Erv5bEC5zEWzV493vb9SdU3oS65G65trqSx1nfsV LVa8tpe/8vDUFGlLS+b6hc5yxe8FGtMt/r33ySu+eV2wUM82fvP+ftEAvm9rrE28A+QL7wuG HPzJOE2JpTgj0VCLuag4EQD5pgKCJgIAAA== Subject: [rtcweb] Direction to Interim meeting in Kista X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 12:02:57 -0000 --------------030309080908010900030009 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit WG, The Interim meeting will be in the conference room Lappland at Nordic Forum. The street address is Torshamnsgatan 35 in Kista. The attached image provides the recommended way to walk from Kista Sub-way station. The walking directions are the following: So when arriving at the subway station take the exit towards the rear of the train if arriving from downtown. From the station you come down the stairs and end up in the Galleria, turn left and go straight through the galleria. You exit the galleria onto the end of a square. In front of you are a street "Kistagången" going uphill. At the far end of the street there is a high rise sticking up. Go towards it. You will cross a bridge over a car street. In the next block after the bridge there is KTH/Electrum on the left. After that building you will have a walkway /bicycle path "Gröndlandsgången" to the left. Take that and then right after just 30-40 meters, up some stairs. Then you arrive on a parking lot, turn left and you get to the entrance. The meeting is in on the entrance floor. If you get lost, please call me +46 73 0949079 and I will try to sort you out. -- 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 ---------------------------------------------------------------------- --------------030309080908010900030009 Content-Type: image/jpeg; name="Nordic Forum.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Nordic Forum.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/4QNSRXhpZgAATU0AKgAAAAgABVEAAAQAAAABAAAAAFEB AAMAAAABAAEAAFECAAEAAAMAAAAASlEDAAEAAAABAAAAAFEEAAEAAAAB/AAAAAAAAAAAAAAA ADMAAGYAAJkAAMwAAP8AKwAAKzMAK2YAK5kAK8wAK/8AVQAAVTMAVWYAVZkAVcwAVf8AgAAA gDMAgGYAgJkAgMwAgP8AqgAAqjMAqmYAqpkAqswAqv8A1QAA1TMA1WYA1ZkA1cwA1f8A/wAA /zMA/2YA/5kA/8wA//8zAAAzADMzAGYzAJkzAMwzAP8zKwAzKzMzK2YzK5kzK8wzK/8zVQAz VTMzVWYzVZkzVcwzVf8zgAAzgDMzgGYzgJkzgMwzgP8zqgAzqjMzqmYzqpkzqswzqv8z1QAz 1TMz1WYz1Zkz1cwz1f8z/wAz/zMz/2Yz/5kz/8wz//9mAABmADNmAGZmAJlmAMxmAP9mKwBm KzNmK2ZmK5lmK8xmK/9mVQBmVTNmVWZmVZlmVcxmVf9mgABmgDNmgGZmgJlmgMxmgP9mqgBm qjNmqmZmqplmqsxmqv9m1QBm1TNm1WZm1Zlm1cxm1f9m/wBm/zNm/2Zm/5lm/8xm//+ZAACZ ADOZAGaZAJmZAMyZAP+ZKwCZKzOZK2aZK5mZK8yZK/+ZVQCZVTOZVWaZVZmZVcyZVf+ZgACZ gDOZgGaZgJmZgMyZgP+ZqgCZqjOZqmaZqpmZqsyZqv+Z1QCZ1TOZ1WaZ1ZmZ1cyZ1f+Z/wCZ /zOZ/2aZ/5mZ/8yZ///MAADMADPMAGbMAJnMAMzMAP/MKwDMKzPMK2bMK5nMK8zMK//MVQDM VTPMVWbMVZnMVczMVf/MgADMgDPMgGbMgJnMgMzMgP/MqgDMqjPMqmbMqpnMqszMqv/M1QDM 1TPM1WbM1ZnM1czM1f/M/wDM/zPM/2bM/5nM/8zM////AAD/ADP/AGb/AJn/AMz/AP//KwD/ KzP/K2b/K5n/K8z/K///VQD/VTP/VWb/VZn/Vcz/Vf//gAD/gDP/gGb/gJn/gMz/gP//qgD/ qjP/qmb/qpn/qsz/qv//1QD/1TP/1Wb/1Zn/1cz/1f///wD//zP//2b//5n//8z///8AAAAA AAAAAAAAAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcGBwcICQsJCAgK CAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAFMAhcDASIAAhEB AxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0 NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3 +Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQA AQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygp KjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaX mJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3 +Pn6/9oADAMBAAIRAxEAPwD6sooor+Mz+awooooAhvTtSNuflkX9Tj+tTVBqBzHEgBLPKmPw YMf0Bqem9imvdR6V8NGGgfAbx5qbqCb822lwZ6FixZ/yXB/CvNa9J+KOfA3wl8LeFcbbq7B1 6/G3BV5AViU+4QHOfavNq9rOv3fscJ1pwSf+KTc381zWfoejmb5PZ4f+SKT9W3J/dzW+QUUV 6t8Bv2T9Z+NNompyXEWk6EXKC5dd8k5BIIjTjIBGCSQPTOCK83CYOrians6Ku/61Zz4HAYjG VVQw0XKT/q76JebOD+Gnw6vvix8RNJ0KwRzJcOZJJQMrbxKAHkb2Ab8TgdSBX038ftKsPhxe 6fbWduYrDT9LhiRE5bCu6AnPU4Aye/Nem/Cn4OeH/hDczWWi2jRutuhmuZW3z3JZm+83t5Yw AABk4Aya5P8AartWjOm3EEavcyQToNwyGKFSo/NjXo8UZJDD8P1lP3pXg300U0rX7JN6/gf0 R4bcPrKsTB1mnUnpLslZtJP13ff0PFNP+IEepX8MEdpNiV9u4kfL78Vr6xo0GuWhhuEJXqrD hkPqKxLObxHLdQmSKKKAOu9RsGVzyOpPSulr8MzCMKFWEsNaLX8subXzdlY/dq6UJJwsvR3M Xwv4duNG8+K4mSe2DgwqRnGOd3PTtx61tUUV5+JxM69R1Km7+RjUqOb5mMtTKbaMziMTFR5g QkruxzjPOM0+qmiRXEFkyXJZpBI5BLbiVLEjn6VbqK0VGbimnr02FJWbRqeEPF154K1hLyyf a3CyIfuTLn7p/wAe1e5+F/Elp8QrBNT0qc2WpW4CPuUM0ffZIoI3xnnuO5BVhkfPFaPhfxRe +ENXjvbGXy5U4ZTykq91Ydwf/rjBANfoPAvHlfJKypVZN0W+m8H3Xl3j13Wt0/AzjJo4qPtK ek1+Pk/Ps/v8voqXUbTxFPBZazbnTdTRj9lmSQhXb1hlwOSBzGwBIDAqy8lLi4vPCcIGqMbu 0XgX8UWNijvMg+5x1dfk4JPljArO8I+MNL+Kvh6RWhikyAt1ZzAPsPuDwykjg45x2IIF+2l1 LwiVFt52raYuB9nkkzdQD1SRj+8Uf3XO7rhzwlf1pgs6wGb0IvENe8vdmtn8+nz09D88qUal GTjbVbo00kWVFdGDKwyCDkEetfGX7WumC6+G3xBiBDKl07DPA/dSp+X3K+vLPSLe+gkv/DVx FEGYiWzkDJbs/UqyY3QSZPOF6sSyMcEeX/Ff4G2vxZ8Ja9psSy6RrmoRXAntZQuZA7NiRedp 4IwykqSMEg5I9PLsLLK60nWd6crWktvK/b128zKpLnWm5+Vtegfst340/wCPXh1ySoeWSL67 4XUD8zVH4zfAzX/gb4ml07WrV1RXKxXCqfLl4zj2bBB2nnnPIIJrfCL4fa78RfFRt/D06W+o 2cRuhKZzA0ahlUsGHOcsOnrX16aaujBM+sP2prrVbL4JavNpM7QSIE+0FB85gLBXCntweT/d DV8X6PrF34f1OG9sbma0u7dt0csTFXQ+oIr72tfC8ur/AA1h0XWWWae401bO9dWLhnMQV2BP J5yQTzXwVrekT+H9Zu7C5Qx3FlM8EqkYIZWII/MUwPoD4c/E7wt+0Jp1xoPjO3jtdcvtnl3v mlUnkVQqtHn5YpMYBUDa+O/3a86+KPwc8Rfs8eKIb63nnNpHLmy1O3ymD/dbH3Gxng8EZxkZ rzqvfv2d/jbqvxEkt/AOs2E3iOPVmS2tmIDSgbh8jljgjHAYnIOOTxhNge0/sa+Itb/aO0CO 1ezezuoZmW51ALmFkzueYDs2WwF6Fjx8obb9JfFLxjbfC3wxbeFfD2ba4aHDSI5L2kZJy+48 mVzuOSc5LMTnGYPCvhPRf2QPgzb6ZpcFs2ozAJGgyRcT4yTnr5SZJJJyeeS7/N5ZcXM19eT3 NzM9xdXUhlmlfG6Rz1Jx07AAcAAAYAAoQEBhihtTGVRYETaVIG0Ljp9MV5P40+FVrq2mDW/D E0V7Z3A8zyoGEisM9YyOo/2f/wBVcn+2D+0B9ljl8JaLcETNxqU8bY2D/niCO5/i9OncgeTf BX4+av8ABnU/9HJvNKmbdcWLthHPTcp52t7jg9weK8fO8hwma0PYYuN+zW8X3T/TZ9UeXmuU YfMKXsq69H1Xp/lsfR3we/aFufBS2umau11c6Vbtm1uIXAu9KJ6tEx6rjgxn5WGR0yD9cfDz 4sWnieyslmuYLhb4f6Hfwgi3viM5Xn/VyjBzG3/AScMF+Rv7P8P/ALQOgNrnhy6jS/AAmib5 SG/uyL1VuuGHBx361jeBPiVrfwY1ee0kgM1jMw+26ZdDMNwPXB6Nxww9B1HFfkuLpYzJJxwm aXnQ2hUS1j2T8v7r1X2W0rP4zDZhjsgrKhjPepPRS/z+XTddLrR/oLRXk/we+P8Ap3iLw6tw t5PeabDhZnmO670rOeLju8YxgTDJxy2cM49WilSeJZI2V0cBlZTkMD0IPpXdOFkpJpxeqa1T XdP+rbPU/TMHjqWKpqpSd0/6/r/O58//ALTf7HsfjKW58Q+Fokg1Z8yXViMLHeHu6dlkPcdG 68HJb5OvbKbTbyW2uIZYLiBzHJHIpV42BwVIPIIPGDX6Z149+0x+yxZ/F+zk1bSVhsvEsK53 Y2pqAAwEf0bgAP8AgeMFfls5yGNe9egrT6ro/wDg/n+J8JxVwZGvzYzAK093HpLzXZ+XX13+ KKKt67oV54Y1i50/ULaW0vbRzHLDIMMjDt/9foaqV8FKLi3GSs0fkUouLcZKzR03hnxsd1ra ancXSWcMyv5kRBLKAV8uQEHfGQcEEZHBBBArl/iH8NtH+Kul3uianpUZcp9ol05pDICgPy3V pMMF1BwQyYkjbGQpxTq2PDni2fRIpLdnlNtMjJmMhZrfcpBeJiDtYZz6HHNe3g8ypzgqGMvZ fDNfFF/qvLfsevgczcHFVJNOLTjNNqUGtU01r+q6Hyp488Iar8DJmbVppdU8Kk4h1plAksR2 S8A4A9JwAh6MEOC6GLaxePALDJH8Le/19/58V9Z+KodP1e+iRFES3qrDBeSlPs+pSlBujkwA sM5O7CEBXGCpySo+bPiT+ztffCW4nvfCVjPcaJDua88PLlprM5yXswew5Jt84wP3eD+7f6zC 5nUoONHG7S+Ga+GS830ff8bH9v8AhJ9Ix3pZLxjJJysqeI+zLolU6J9Ofb+e1nJ8pq+i2viW 1jSdZo5LeQTQyxSNDcWkgziSORSGRxk4ZSOCeoPPcfDD9oK78PX1vonja5ikjncRWOv7Viiu GJwsNyoAWKU9A4xHIeAEYqjcRpmqWfijT4r2wuY5omJCSxnOCDhkYdQQQQynBBB6EcSXEcOq 289jewQyxzoySQyKHjnjIwRg8MCDgg+voQT6GYZbRxlPkqrXo+q/rsfv3iN4X5JxrgPYY+Nq iX7urG3NFvaz+1F9YvR9LOzX1b4P8Zap4B8RW2q6PezWF/aNujljP5qQeGUjgqQQRXvc37X1 p8bn0rSfE0EXh5bU+Z9tgJliluCuwF1IBjjwz8ZbnaScCvzn8AfFzU/gZstdSbUNd8GA4WQA 3F9oS5/76mtlHYbpYwON68J9BaRrFp4g0u3vrC5t72yu41lgngkEkcyEZDKw4II7ivkKmLzD K6NTLqlp0Kl04vWMk9Gu8W1vZp7O+zP86OKeGuKPDrMlhMV8DfNCaV6c0usW9n/NHRrrdWb+ odb0C50CdUnVSkg3RyxndFMMA7kbow5FUq82+Evx4n8FWn9j6vC2q+HpWz5RI86yY9XhY9Dy flPB9snPrd9pFvc6VDq2j3Q1TRbkbo7lBzEc/ckH8LDIGDjmvyTiHg32VOWPyq86K1lF6zp+ v80O00tPtKOl/wBi4M4/wed01Tk+Sst4vr5ruZtFFFfAn6Act/wgtxbeJxc2sqQW6uJAc5Zf VcDt1/A1Ru9cvdB8ZFruZ5I1O08YUxnuB/nkV29YHxA0I6npguI1zNa5PA5Ze4/Dr+dfSZfm vt68aWMScXHkvbVed9/X7zuo4jnmo1dmrG8jiRAykMrDII5BFQ6okEmnzLcsqwMhDljgAGua 0zxDe6H4PWSW1djG4jiaTIG0jIJHXA6DtjFY8y6h4o3XN1KIrWPJMsp2Qxj2/lxzU4bIZurK UpqMYu11q2+lkuv4+TI+rqHNUqSUYx3d+x0PgXw9DZK15DefaRICmFXaoGe4POeB6fjXD/GP wouia2t5Aqpb32SVAwFcdfz6/nVqb4l23haxktdGaS7lkOWnmUrGD6qnXPTr6d643VNXutcu jNdzyXEp4yxzj2HpX1eW5fi442eKqT916Wa1a6XSta3pfdWVz+dvFnjfJcyw7y/DP201JNTW kYtb2f2rq60063uj6V/4J3eGCI/EutOkgUmKyibOEPV3GO5GY/pn3NeY/td/tH6tonwv8T+O bWFdS1S00u7udCsZUZoYVSF5YkZFIY52p5m07nbABAC7fpT4U+E5vgF+zHcSGLy9UtdOuNWu VZeRP5RfaQe6hVQ/7tfF37Yeo6h4e+E+pLoMD3OsaboV9NYQRwmV5Zlh/cqsY5Yl0xtA54Ar +nuD4Ry7Be3qJXg4LXZOUrO/zl/SPNw0ZZVkUE9JJXfrJ/pe3yL/AMQv2W/iQ/we+Gq/Fvxl o2g+OPiRr8egafYaB4enurLS7y5tp7mOO9MmoIHSNLWRS8KBgzY/ej5x3/8AwTr+MXxL8GfF /wCIPgP4xr4eg1qLxKNKil0hJktpLlNNtZorg+YzE/b4PMlBBUeZbTAqHkwcDW/20of20fFn wZ8R3tlfeCvDfgLW7bxZrGh3vhjXLjxQdVjtLy2Fnaww2bw3UDG5UiRH34HKAnaPEx+1hrPx s/aa8X+OPEXhrxb4A8I+K9WGn6WuqabJa30FpaR20cOoIjAbpobuEzALkKyNESQGB/S+KKGE WX1MQ4Q5m0pONm4ty0UbPW0VeyvpZ311/QOG4YjOmsuw9XmVOM5QirO7STa9ZbetuiP1iIDA ggEHqK+bvjR4Wf4b+IJYoIHe1u8vYgcgjGSmTjOw5yMk7dpPWvX/AIFfEuT4neAori9+zx65 pshsNXhgOY47pFUlk/6ZSoyTRnvFNGe9N+PHhdPEnglXVGe7sbhJLVVALSSN+6EYz/eMmOTj JB7V/O3GXDX9q4N0FG9WDvDzf8vpLb1s+h0ZRj/quIUpfC9H/XkfPHh3UrbUtP3WrOyRsVJc YYt1JP1zmivU/BX7Huo2XmPe6jYacszGR4oFe6Y56DJ2BcewbPr3or8zXglxPWvUp0VCL2U5 x5vnZtfjfukfV1uJsujNqEm16M+L6KKK7z+HAooooArnE2pAZB8hM492PH5AH866P4deDZ/i B4203SLdWLXkyq7D/lnH1dz7BQT+Fc/pcbXRZo1Z3uZPkVQSW6KuPXIAP417D4h1FP2c/By6 FYLGPGOtW4fVbwEM+nxPytunoxGCT+PPylfXyvBU6knXxLtSp2cu77RX96Wtuyu3oj0sFhoT k6tbSnC3N5/3V5t39Fd9Dlfj94tg8a/FvWb21cPZrKLe3IOVKRqEBHsdpP41xtFFcONxU8Ti J4ipvNuT9W7nHicRKvWnWnvJtv5u46KJp5VRFZ3chVUDJJPavu26S6+AnwQ0HT7BLUXFmsVr MxUsm8ozSOvTkyAnn16V8qfsp+FYvF3x78PwTkiG1mN6QDyxiUyKPcblXPtmvrf9oxR/wr+O QsqpFdo7EnAA2uP617eDpzoZPi8ZTdp8k+V9uWLaa+f5H6z4W5dF1Hipq/NKMPldN/fdfceR 63+0H4q0+x1DULe9hRvOVBi3jIZVwhzkHo27/JrAtfi1rPxOad9VnWeSzGYVC7QN2c8DjqB0 qCLSf7S8MrbTM6Ncp5khwMhmO8/qTVG3stK+HEL3d7qcFnDMRH5l3MkUZPJABOOcA9+gNfj1 XiTFYzBVMNia05zk7JXlZrTRpaPZ9D+n8Ll+DhC0KS576aXZX/trxHdY2WMcYPqmP/QjXU1y lt4Uu9Zt47hNcae2uFEkUkbtIjqRkFTuwQRggiuotomgt40Zi7IoUtjG7A614mayoPlVHlur 3UVJfe3udmJ5NFG3yT/UyE8TTyeIrqwEUamGNmRuSWOARx+NP8HeIZvENlLJMsaPHJt+QEDG B6k+9SL4bC+Jm1LziCy7fLC4H3ccnPNO8PeHIvDqTLFJJIspBw2MDHpRXqYL2DjTXvWh0e+v N/X3BOVLkaW9l9/Usae1z5tyLhRtEp8kjHKYHp7561Zooryak+Z3tb0OaTu7hRRRUiL3h7xF eeFtWivbGUwzxfirjurDup9P6gGvonwR4mHjHwtZ6kIvJNyp3JncFZWKkA9xkGvmivfPgPcL L8M7JFJJgklRvqZGb+TCv2DwmzOu8TVwEpNw5eZLommk7dr3PleJ8PD2cayWt7fg/wDI6LUd EM1ybuzmax1EKFW4RQwcDkLIvR05PB5G47SpOaq2+u2fjK2gtNbtxYXbufsdwku1Zm6BoJBy rkZ+Q4YjcPnXJPzh4w/b71nSvGupW2maZo13pFtctFbSOsollRTjcSHx82Mj5eARXo37Lv7Q Vj8f/CU+mX9ha2l/ZQRiS1aQSrdRFQN4BAJw3DDBxleecV+/ZPxbTpVXhYz51qnF36b2bVv0 Z+UYTiTLcZiPq1Gfv3aWj1t2e3Q6H40/B/TfHnhifTPFlpHqOnSR7F1RYsvAAcgzquNoHXeu FB3H91xnwLwv+zBo/wADNda8tdHmsLydJII7g3bzx3EO8fMp3FSGCo2CNwBGQOlfVlrd6j4T IAa41bTByUZi95bj/ZYn96o9G+frgucLWZ4l8LaZHolvfWSLJo2ozQLLYlCIW8+RUWWMcNE4 LgnGARu+Xcdw+8wWJpKm62Dd4LVwe678vb02fRo9mcXfXc8Lrxb9oX9lC3+IUtxrWglLTW5M vNCzYhvT65P3HPr0PfGS1fSvxB+FV34NZ7mAtd6YASZf44MdnHpj+IccHO3jPJ17WGxVLEQV Si7pkNWdmfnjf+GtR0zXm0u4srmHUVlEP2ZoyJC5OAoHck9Mdc1+gH/BOf8AZVi+Hl82vajC suqWsP72QgMsc8g4jQ/9M49271MqnkBcVtX8GaNf69a65d6dbzalpit5Fx5eZUGDkcfe74Bz gk4wTXvOoSP8EvgZFACIda1H91lWBK3UoLMQeh8tA2PURAVuxHxj+3V+2lr1z8fL/TfDWoQw aboSmxRvJSYM4OZGBYMPmIHK9QFB+6K4XSf2zNTtvhNqEF5cy3viq5uWS3m8hIo7aAouH+QA Fgd2ARnJBOQMVN+178CdH8HRHxLp15HZSX9xtksHJbz3blnjPUdywPHPBHAPgdNAPnnkup3l ld5JZGLO7ElmJOSST1JNMoooA3fhz4x1vwT4stbvQJpo9QkcQpGi7xcbiB5ZX+IE4GPXpziv tfWPAw+IPhW0Os20FlrPkKXeBt4gkI5UH+Jc9vyPevLf2RP2fT4ds08U63bBdQuFzp8Mg5to yP8AWEdmYHj0HueKf7Wf7R82kXLeGPD11JBdRMDf3cTbWiIIIiRhyDn7x+g/vCufFYSjiaUq GIipRlo09v6/IwxOGpYim6VaKlF7pmhGdf8Agb4xhu7aV7W5iJ8qZOYrlOMqR/Ep4yp/wNfR 3wB+P8PiMhdOaKKQgveaDJJhlIGTLZE8bTgkxHgdQV5LfMvwX/ab074mWEfhvxotul5KBHBe N8sdy3QbscRye4wCfQ4B7Twx4KuvhF8XPD2qKzXOmrqEaGYHa0au2wh/Thjz0PtnFfk+N4ax WS1lLC3qYSclzJ6yp3avJei69laS0TPg3luLyXERq4VuVBtX7xu9/wDg7P7S0TPtfwz4o0/x losGo6Xdw3tlcDKSxnIPqCOoI6EHBB4Iq/Xw3B8Vdc/Zw+N2vx6XcedZLqEons5CTDcoXJGR /C4BGGHI6cjIP1r8H/jZonxp8PreaXOEuYx/pNlIQJ7Y+47qezDg+xyB4+EzGnWnOi9JwbTX o7XXdfl+f1uR8S0MdKWHn7tWN0497dY/5brz3MP9oj9m7TvjjowliMNhr9qv+jXm3iQf885c clD2PVTyOMg/FfjrwBrHw11+TTNasZbK7jG4BuVkXsysOGX3B9R1Ffo/XOfE34UaH8XdAbT9 atFnVQfJnTCz2rHHzRtg4PA45BwMgiuPNskp4tOcfdn37+v+f5nDxLwhSzG+Ioe7V/CXr5+f 3+X51UV6F8dP2ctb+CGpFp0a/wBGmbEGoRIQh/2XHOxvYnB5wTg489r8+xOGqUKjp1VZo/GM Xg62FqujiIuMl0f9beZb0nWJNJmJVIp4ZMebBKoeKYA5AZTwefyrf8S6zpuu6WL64+3SAySS XN3tRm0pTjaroigyQAlh5gBZAF3cZI5Wp9P1GfSryO4tpXhmiOVZTgj/ABHtXZgMx9ivY148 9N7x/VPo/wCma4TG+z/d1VzQe6/VPo/6Z5h8cP2bJ7jVZNd8NNZ6fr9wqzSozf8AEu16PHDO VBw5XhZ0BPQMHVQo8k0bXI9ea6tbi1utO1PTZPKvbC6Xy7izkxkZx1BHKupKsDkEivs+31my 1vQXgFkSbK2Ih0myhhhEj79zSwNgYkILZjJ2sQMYOTXlPxn+AOlfFOxttVtLtrbUbTdFp+uW 0WJrc5y1vNG2CVz9+CTBBGRtYBh9Tg8bLCU1Ui3Uw7dk/tQ8pL+vLsf014Q+O2M4WUMvzRyx GXN2T3nR9O8f7vT7L6PxZC0SqrsXJ43Y6/XHQ/p9OlR+FPEesfBnVJLzw/Ct9o9zKZtQ0MsE WVjndNasSFimJ5Kn93IRzsZjJVe5udQ8KeI10DxNaxabrEm42zIxa01VAMmS3c4yQOWjPzp3 BXa7XuVJJOV/UV9FUp0MXRtK0oyP7lx+X8PcbZGqdVRxOFrK6ad/Rxe8ZL5NO6fVHuvw8+JG j/FPw3HquiXa3VsXMUilSk1tKv3opUbDRyL3VgCOOxFeg/DT4qat8LNZN1p0waCYbLm1k+aG 5T0ZfX0I5H5g/HkVrfeHPEB13w5eLpetEKJWKlrbUkUfLFcxgjeoz8rAh0ydrAFlb2f4R/HC x+JyyWNxA2j+I7NN91pk0gZtucebC/AlhJ6OoBGQGCNlR8Lj8qxOW1VicNJ2WzW69fy7Pr2P 88PFfwRzngfEf2jgZSq4S/u1F8UOyqJbdlJe7Lyb5T7L0DVdI+JukSaj4ekZJ4UMl3pUjbri 2x1Kf89E9CMn154qskiyorowZWGQQcgj1rwDQPEF74W1i31DTrmW0vLVw8csZwyn+o9QeCOD Xt/gX4laf8W1EMrWmj+KP+eRPl2mqk/3T0jlJ7fdYn3yvxmccJ4XN71stiqWIe9PaFT/AAdI Tf8AJpF/Zs7RfZwT4rKty4PNvi2Uu/r5/j2vdJaNFN8wpdT28iSQ3Nq2yaGRdskTehH8j0I5 BIrt/gr8PP8AhMddN5cqDp2nOCwPImlGCE9CAMFh6EDBDcfnOV8P4vG5istUXGd7Sun7qW7a 8vx0XU/aK2Y0IYf61GSlHpZ7+h4t42+LNhpazWltEl/cLlWDjMKEHof734enWvOfEHiu+8Tz K13MWRPuRqNsafQCvsP9pb9l7RfiVpV9rtqU0rXbWB5WmRf3V2FGcSqO+ARvHPPO7AA+Kq/W KvC1PJmo01dO9pPd7X9Om2jP5b8RM9zyviPYY2pajLWMYaRaXdXu2tN2/IK5TT/2nvDnwP8A 2xvAOjeNo518HanpOo6vdTWmmXN/crcWtxYpCuyFX/dH7S5fKEnaADnhurrHtfg9D4v+NGke JbZrt9Z03SbzR4ow6i2WC5mtZZJJBt3ZVrSIAhgMMwwxK49LJKbqY2EI0/aN3tFdXZ2+V9W9 kt9D4TJlfFwtDnfSPd9L+V9/I9b1L/gsb4T8Q/s2Xl5rFlLqepeLdZ8XaZptppCx2jJoWmaz c6auozLezRMrmBYmMS5lklLhIcKwT508fftw6RrXxA8RRJHFrcUWp21h4Xt9Llhiudbs30XT dUe4zcyxRAL/AGg3zF0G3y1wXI3XfiH+wl4M8JC2TSdd8QQeIfM1p7q7MdjdExarfPfzptnt 5Fj8u4djAY9roGbc75JbqPh5/wAEj5/jv4jj8SWeoa94bmGonUYdduVt7how+nWmmyRQxTwy JKjQ2UD/ADKcSR53gfJX67xBiMJTw08lhrUnZyS1UbapSeltUr9bX2ur/q2f46GMj/ZcU5VJ Wuo6pW11fTW1/LtoeXaH+3j4T1a/s7rQbTxLqmnLDpd7LrFlbxrbacl/cPb2zvvkWXImidWW NHaPbkgDmuu/ai/bF8LfE/4ZeNLeG1m0jV7Ww1/XfD+o3y2smn3viHSbW5k1WwVIZzcwxXKW kkwE0UCvNazGOSUODX2F4O/4I+fC7wj4P8QaWNQ8W3tx4n07RNPvdQubq3kuk/su6kuo5Yma E7HmklYS53BlAChDknP8ef8ABGX4a+PtF8W6Pca14ntvD/iaLWjBplvFp8SaVc6oZWmuEnW2 FzMYpJpJIY7iaSOIsAFKpGE8/JMtwWDU1KTtLputLNP1vfaytp5nscH5TiMhxP13C1HGelle 9vN93rJaaWZF4P8Ajv4Q/ZkbwpfWt3rk+kr4gtfhZ4klu4lJF59iF5aXmVIURQrJ5LPgHypB uyIFzpS/8FTPh941+FK6xeeFviBpljregaP4n0C2vbK3S58VWeo3tva2gsxFcNsle5ngiCzm EgzI4Pl5kFT4Y/sP6B8aNcn1jxB4q8YRHSfFsWta/wCCUexbRl162sI7B5SWtTdNbz2ojlER m2ET78BiNuH4b/YA8J3tivwv1zWPFiax8MfB2maF4P1OOe3SefSrC+tr3Tb9cQBWvLW7soIp OPLYIpaMrPivdlDDJ63vG3fa/wDWva1j6KrWqVajqTd3Jtvzb1Z63+yF8ZNY/ahh+JTeKdJ8 S+G5/BfjGXw3bade3Ztb2GGPT7C5H2gWszQPJvuX+eJ2RkCMrMDuJXVfBf4U6F+zB4f8Uanf eMNV1eXxxrv/AAkOp6r4hntImkupLS2tQiCGKGNI/KtYtqBSQd3JGACuHF5rUdRv2r6faf6v uc8q9Gn7tSST82kfNX7Sf7Oup/B3XpLyPTpYtCunzFJGzTQW7E8R+Yecf3d+G6j5sbm8tr9I U8QTWlnJa6xAus6bIpV51hDShcdJoQMOPVoxzn7igE1478WP2EdC8a7NZ8F3kdkly4lktkkE 1vMhbLNCxPytjOFJ2ZwMoOR5vEPh37aUsTk79ab0a9L/AJP5Nn5dnvA83N1svtq/h0X/AIC9 reT2/A8M+EH7Kfif4x6Mmp2ZsbDS3colxduw83acNsVQScHIycDIIzXpmk/8E9rbVbYGTxTd FO8sNkEWQ9wmXJK/7XGe3rXunhSPTtK07T/D6wvottZRLbw6ddYjnuNq8jg7ZFHOShYMc5OM g7viTVH0PQrm5ht57mSCNnSGFC8km1SdqqOSTjAA7kVx4ThWhSnGjUh7/Vyv83bt122PpMBw VlmHoKWIjzyS1bbtfrZK2nbqfLnjL4V+F/2RRDqzXUniLXXyml208SxwwOBzKygnITIx7kY5 5XwPW9auvEWr3N/ezNPd3kjSyyN1Zick/wD1q2fit4u1rxp43vbzXkuLe+DFPs0qNGbRQeIw pwVA+mTyTyTXOV8TnmYwrVPq+FjyUYPRWs2+speb/BWXdv8AKc4x1OtVdLDQ5KUW7R8+rd9b vz2WgUUUV4R456h+xtMIv2jfDwJChxcrz/17S/1r6o/aTQXXw7NqACZ513juI+jH/wAeA+rC vjz9nS7ay+OnhV1JBbUYo+M9GO0/oa+xfjchvPCWqygblszBD7oS4ZvwIaP8q+npSf8Aq5i/ KNT/ANIuft3hVO9Lk7VU/v5f8jxGuZ+K/wAL7P4t+GY9Lvp7i3hS4W43w435UMMDOR0Y9Qa6 aiv5vwuKq4arGvQlyyi7p9mf0vRrTpTVSm7NbMz/AAn4ch8H+GrDSreSaWDT4VgjeUguyqMD JAA/IVoVwnx5+M0nwY0KyvI9NXUTeTGHDT+UIztJB+6c9PatD4L/ABJf4r+BIdYktUs5JJZI miRy4XacdSB1GK9CvlWOlg/7VqRvTnJrmutXd30vdap9Dqq4LEOh9emvdk7XutXr03Orooor yDgCiiigAooooA9X8FfA3RPFPhew1FrvVA9zEC6rJHsDjhgPkJxuB70/44avZ/s/fAXV20t5 ILi9JtrUu7FzNKNpYEdCqKzDoMp+e3+z/q8N98P47VGHm2EsiSKSM/MxcHHodxGf9k+leO/8 FE/EOIfDGkpL95p7uWL6BEjb9ZB+df1BlOGwGEyiGYYOlGEpU4+8kr3klo3v8Vrruj8X42zX EYbBYiUptuN0tdm3yppeV7o+WtRYpp87A4KxsR+Ve5/sJfDiXxH8UzrJMiWXh2ItuViN8sis iJxyRt3sf90A8GvDriCS8MUEKPLNcTRxIiAszkuBtAHUmv0F+Avwwg+Cvwrs9OlMcd1sN3qM pYbTMwBck5xhQAoPTCA9zXFw3gXWxCrNaQ/Pp925+NcFZQ8ZjY1pL3Kb5n6/ZX36+iZ1usax FotqskiySySuI4YYxuluJDnCIO5OCecAAEkgAkJZ+EbqbwQdPmlhtrtrl7qNgpmSE/aTNGCP l3bflB5HQ896g0yeKys5/EuoxSKzJ5dnEV/eJEzAKqg8iSZtvHB5jUgFTnF8URR2mmvrHiLU NUinwVW3sNTuLaKIN0iRY3QSMOfncbjyflXCr+8ZfRpZbSTrpyqVdOVb27f5/cftE25PTZE3 xB8Rap4G8J3k91bxysse2O9t1PkoTgbpEbJjxknksvy4LAkA+GjgADoK9I8IftFy6FcNBq1t cXOmZxDLETNcWiDgB8/NMAOrffyOjk8T+M/gjp2u6CuueCgjrModbGGRVtrgdD5e4gRMOm3I X5SNoJJr6LA4CjhVL2Mbc2r/AMvl+plKTlqzm/gt4KPjbxzE8qFtP0ZkupyejyA5ij/76G84 7IARhxVT9pn4iw6v4yjZGll07w200RESF2kmEbmYgDltu1UAxkMr+tega1IPgD8H47G2kRtd 1RiolTkG4dcyTc/wRqMLn+7Gp5NeJahCLW3tSpYiCZACTkncdmSe5+au2WwkfD3xp+LN98X/ ABpNqFyJIbWLMdpbFsi3jz0/3j1J7n2Arka+nP2jvgFo3ijxjax6Sp0fX9WUyRl4itjqDjJZ NwB2TYG7phh7nNeEfFf4YX3wk8Xy6RfS287qgljlhbIkQ9CR1U8Hg+ncYJoRzVe0/sofs+f8 J9qieINYgzolk+YInHF7KD6d0UjnsTxyNwrkfgF8Frn4zeLxbEyQaVZ4kvbhRyq9kXtvbBx6 AE9sH6t+JfxC0f8AZ/8Ah3HIIY444EFrp9nHwZGC8KP9kAZJP8yMgHPftPfH2P4U+Hjp+nyq 3iDUYz5QGCbRDwZT7/3QepBPQV8dTTPcSvJI7SSSEszMcliepJ7mtDxb4sv/ABx4iutV1Odr i9vH3yOeAOwUDsAMADsBWbQAV7l+z3+1jdeFGttE8SNLfaVxHDdE7prQdg2fvRj81HqABXhy qXYAAkngAck12Pjj4JeJPhz4XsdS1HT3js9RjWRpF+Y25PSOQdUbocHjOB1BFJoTR9qePfhx o37Qth/bWjz2tr4iuY1kSUTbrXVlCgDBzhXwBgjg9+uR4jpWr698IvGYmt3u9H1nTZMMCCrK epVgeGU9wcgg9xXk/wAEP2htY+DOoKkTPe6RI+ZrJ3IC+rRn+Bv0PfsR9g2OseEv2qfCEUs1 0ItQgXyodRUD7RaNjiK4QfeAPv7g85P5rxbwJHFyePy33Ky1a2Un38peez69z4viDhVV5fW8 C+SqtdNLvv5S8+vXuesfs7ftV6b8Y4Y9N1AQ6Z4jReYM4iu8Dloie/GSh5A6ZAJHrdfnR458 Aa18JvEq22oRSWtxG3m21xE3ySgHiSNx7/iO+DX0J+zj+2ml+LfRPGlxHFPkR2+qt8qSeizd lP8At8DH3scsfgcBnMvaPCY+PJUjprpd+a6P8H07D4f4xbn9RzX3ai05npfyl2fns/Lr9Gan pltrWnzWl5bw3VrcKUlilQOkinsQeCK+f9T/AGCdNHxQsbyyuyPC7SmW7sZWYyxgcrGjdWRj wSSGA7sea+hlcOoZSGVhkEcg0teziMJRr29rFOzuv6/TZn2OYZPhMdyvEwUuV3X+Xo+q2PmL 9ob9iQr9o1nwVEzZJkm0rI49TCT+ew++09Fr5nubeSzuJIZo3iliYo6OpVkYHBBB6EGv01ry v4//ALK+j/GW3mvrURaX4iCfJdqvyXBA4WVR19N4+YDHUALXz+bcOwrXq4bSXbo/8n+HpufF cR8DQq3xOXLll1j0fp2flt6Hw4rFSCCQRyCO1dZ4Z8U2+pSG2vjaWkt5NGbq6a3VhfIoK7Je hDbTxIDkFVzkAg53xB+HWsfC/wASS6VrVm9rdR/Mp6xzJ2dG6Mp9R3BBwQRWHXyWHxOIwVVq 1ns09n5NH5fTq18JVcWrNaNNfg0xnxH+Gei/EjRdS0y8sJbm0t3Bu7C6Gy705wSY5QVOQMjc k0bdejAivm3x14U1b4EuW1y7bVPDLyBLfXDGEe03NhY7wKAq9QBOAsbHhhGdu/6w8PeKEtJ4 TeRRySW0ckVpdmMPNY71Knbn7ydCUPBwPSpPE/hmx1W4Wztmjnurq1EjQeRst9SGz96bcEsC Ad26Inco7EEE/R4PE8t8RlqbjvOm913cfLz3XW9j9a8N/E/NuEsW8Xkz56EtatCTdn3ceztt Ja9JKSVj5PJJwVII/Q1R1XSIdfSJlmuLS8spfMtru2k8u5spQOHRuxwcEHKspIIZWIPR/EX4 F3/wjL33ha0udS8MpzcaNGDJdaUADlrUHmSId4PvKM+XkbYhz2l6paeJdKh1DTrmG4guU3Qz xkOjjP6jOQR1HPQ19Tg8bRxdLnpO66p7rya/pH+jXBHHuQ8bZU8Tl8lOLVqlOSXNG61jOOuj 1s9YyV7Pc9G+Fv7QEv2u20Txg9ta6hMyw2eqIBFaamxwFQgk+TOScbCdrkjYckovrCsVIIJB HII7V8x3ltb63ZTWN9bxSx3MZWWCQb0kQ8Ec9R/iM4yK6n4PfE7W/BWuWHh3UUvNe0K8kS1s LzLz39jI77Ujmzkyw5KqJfvpxv3LukX5fNuGnf2uCV/7v+X+X3dj+S/Gj6NksGqmecIwcqau 50d3Fbt0+rj3huvs3Wi+1vhN8UB8TL2y8OeIpmXU3At9K1kDM8T/AMEM3/PVCePm5BPXncPs DwVpEWh+E9PtoYliVIFLADqxGWJ9ySTXxh8OvgxJNq1pHDFf6lrihZ0js2aMWzA5D71I2Ybg OzKuQOhr0rTvGXiz4TeJ0ju7nWjcwrHNcabqN812s8JJ4Vmd1UkBgGRuGXDZAK1+hZZwpiY0 VLGSg8Ta195uHSMn1s9nr0V2krfmHDNDH4XCeyx0r63tdu3r0b6X3tpd2R137ZHx8Pwz8Mro GnhH1bXbdw7k/wDHrAcoXx3ZvmC+m0nsM/GVfT3x4+E2oftTeNLDXfCd3ps1lbaellcrczGG a1lEsjFXTBYcOCOOQMjIwT5149/ZD1v4badDNqesaE010xjtre2klklmIGScMigIvG5ieMgc sVVvz7N8pzTG472EKTdtIrReu7Xzv+h8LxTlubZhmE3Gk3COkeit317vdnl2laVc67qMdpaR +bPL+CoO7MewH+ea9C0vSLrQSnh3wvZz6x4jvQGneKLeYgeN7dgBngHhQcnr83c/Af4Dy69d NY2LPFBEynU9TKAlTjIjQHIMhB4XkIDubOVV/pnwL8NNC+GtjJb6JpsFisx3TSDLzTtknMkj Eu5yTyxPWvu8BlNLIcM6dKSeKmvelvyJ9I3/AF3erVrI+pyLhV4Kh7skqkt5btLtG/5vrq07 WPHPgh+yDpnw5t18Q+NJINR1UN5nkOfNt4HYgDcCP3spY4HUbjgBjg17Qvi2JbZJzp+tR2bE oJW06ZdpU4IMZXzFHH3igUjkGpY4or74iWEc0yA2dnNcQ27gHznLxoZV94lJU+1yK8x+Kf7c Ft8JvjRfeGb/AEGa40/TfLWa7t7kNMxeGOUFY2ULxv24L89cjpXoYLKcuw2BWLxtTkU3a/m2 9ZNptttNts9lPBZRStpGLerercn1k+/m9D1uyvoNSs4ri2miuLedQ8csbh0kUjIYEcEEdxUt c/pGpaT4w8M23i/wokc0V3medIIyj3yZxIrKOsykZGRnKlcgOTW5Z3kWoWkVxbypNBOgkjkQ hldSMhgR1BHNc+Z5bLCSi1LmhJXUlsz26NWNSKlF3uea/FGJfhB8Qbf4hQhk0m8ji0rxQirl Rbhz9nvjyMGB3KucH9zKxP8AqlFanxy+Ht54o0zT9d0JIz4u8JSvfaTvbYl3lds1nI3aKePK EnIVvLkwTGK7PU9Mtta024sryCG6tLuJoZ4ZUDxzIwIZWB4IIJBB6g1wHwS1KXwPqd38OtSu Zri78PQLPo9xOcyahpRbZES38ckB/cyHqdsTtzKK5YTbSmt4/iv+Bt6ehbR5T8cvh0f2iPhd 4c8VeFzeXl/aWaQNYyBllmi3bW+Qn5JopNyyIeVIYE/INxXb/E3UbP8AZp8SXvia8Fxb+A/E Fx9o1eS2R2fQ9QKhVulVFLeVcYEcgHSUxtj97KwK8nG8LUsbVeIhGTv/AC/ro9V+O/U+Pzfg 3BY/EvFVJuMpb2tZvvseq/2Vc3cge6uIRt5Agi2HPoWYtkD2A/pVb/hGrnR72W+0aYR30rBp IZ3Y295zyrgfdYjgSAFl4JDqNh8w8Y+I9Q8a/tTaLoem391bWWhwmW9NvIVByN7q2DyCBEmO xJ/D2PULGLVLCe2nVmhuY2ikCsUJVhggEEEcHqDmvTyzPa8ZSVKTUYO3R3ta9r3sunqfdY7A OjGDlZucea3a97X9VqfI/i79t/x749/bPg8NeGPhr4h8R/DxbbU9C0qSa606y0nxdq1pKn9o yySXDtcrBZGPyYjHb7JpZLg7mWOPP0j8O418a6JJcWTz6JqmkzmyvrVJJL/TIrtY4zLFDLKi efFGzeWWgKKJI5EIWSN0X5h8Y+NG8QfEe/0bxH4r1zQfFnhqXUtH8NeMoYIp5dFiu0jtpZHg bbGzCOFJEdg22T5mVxuU8RpOu+Nv2WfiHrbLoXjXTfCPhbTRpmg+FDc3L2HiC93T2Wn6ZaXT Hyp7nUJ3tNS+3whriA/bY7shShj/AEbK82wWbUpSpauN1KL+KL1Vn2vrtufLZdmlHFxcqT1i 7NPdO/X7tD7Y8c+BYvFdobbxJ4Ws9etUysc9ttkeMd22vteMnHSNnPvXjPi39ifwh4iuSmg6 5e6DfzFmSyvkLZA6BY5NkoH+0S3HrXb/AAQ+O1/4jjsfC2v+IPD2m/FDS9MiuPEPh9YZpLe1 k+XzfsskriS4jjaWONplkkXLLuWNnCD0m71+4nsJINY0FLu3k4cWsiXURX1ZJAjHp91Vevnc 14byavN0qr5Jf3treTdvwkaY3KMJjVfE0lLz2f3rU+KvHf7G/jnwRE8yafFrVsnJk05zKw/7 ZkBz+CmvLZYngkZHVkdDhlYYIPoa/RVZPBsSqd9zoUKnIVmutJgz7KfLQ/lzWL4y/Z58JfG2 2aabUTqJT5Vnha3kdOCADKqeYQPQvjivkcb4XOonPA1o/O9v1t97Picz4BpSXNgZuL7S1X3r VfNM+Rf2UtEOvftA+GojkLDO1yTjOPLjZx+ZUD8a+u/iZJ5vwZ1G5cBTeNHP74edCgPuF2j8 K5r4Y/saP8F/E17q2j6xFqc1zZPaRRXkJhMBYg7w67sngDG3pnnnjU/aU8fWXwf+AfiHW/Fm j6sNC0O0W4uP7Ekiupn2unlxQrIYy8jybEUFQCW6jrXK+B81p5RXwPJeVSM0rNWvKPKtei23 Pq+BMvnlVJLFaS5+Z210Vv8AJnj1FbmhWvg7xx4p1zTPDni2bWToF7Bpdzd22jXNxpwvZXMf 2ZbyMGF5EcYlVC3kkgSbDxWt/wAKL1q5tDNYS6XqyjBxZ3QY4IBBywUcgg9elfzvmPhfxNgn arhW77crjK9uyTv+B+10c/wNTapb1TX/AAD5t/bY0z7Z8JracbQ1nqMbnI5KlHXA/Ej8qZ+x HqbXXwsvbdmBNpqLhRjGFaOM/wA91eh/tUfAPxfr/wAJL2xs/D2o3t80sMkcVtGJ2bEi55Qk Dgk/QGuH/ZT+G3iH4XaJq9l4h0u60ma4uElhScqC42lW+UEkEEDqB2r1qmDr0eD6mHxUHCca l0pJptXWqT1a1evkz7vD5jha2QypKrFyU9FzK/Tpe/VnrFFFFflZ84FFFFABRRVXW9RbSdLm uFiaYxDO0fzPtV06cpzUI7vQcYttJHZ/CDxr/wAIZ4whMrhbK+xBcZOAoz8r9cfKx6norNXl /wC3Xr41j46PbqwYaXYw2xx0BO6Q/j+8FVdV1Ca6+za5ZO7iP93NCSSIz6Y9D/gfpR8Pfs1e I/if4wkTSLE22mzfvmu7nKQ2wIyUJwSWB42gE8gnA5r9i4UxeJeX/wBj25ne67xs/ei12Ts0 9tW9rH494x5NipYOlUwkObnklK26aTtp2fV3SVl3N/8AYq+EJ8W/EO08RXkAk0/RJyYAw4ku BGxDD18vcp9i6e9fXUtt/wAJZrR0/AbT7Iq98eqytgMlufYghnH93aCCJDjmvDHhG3+E2i6J oOjxpLNBavaw7/l+0TuyMZG56fJI7Y5CqQM8Cum1G2Oh6XbaDp80wursNJc3WcSxoTmSYkYx I7EhcYAJJAwhFf0FwhklLC0PrFf4Iavzl/wOny8zwchylZdgoYZfG9ZPzf6Lb5XK2u+IoLu7 m1S5l8vR9FZliOM/aJvuNJ7hSTGo7kueRsNePePvHM/jnVlmdPKtoMrBF1KA9ST6nAz9BVz4 m+NI9fu4tPsFSLSNM/dwJHwr4G3dgcYA4X2+uByk06W0LSSOkcaDLMxwqj1JNffYDCSlN43E L35bL+WPRevf7u9/UlLoth1b3gn4m6x8PWZbGRLmzZjI9lOcROx67WALRk46jIySSrGvA/2y fH1toHwrn0uK+ij1PUZoVWFJQJlQNvL4HIX5AM++K2/2WNPu7P4J6TNe3Fzc3F+XuSZpGkKq WIQAnoNiqce5r1yT6q1bTdF/aN8Nx3dlO9lrOmKyoJADJal8ExyqD80bFAcg87flPBFeLeN9 GvfC0s1nqNu1td2rxysh5V0EgO9G/iQ7Tg/gQCCBa0jWLzw5qsV/p1w1pewcLIBkOuQSjj+J DgZX2BGCAR65Y6poP7SPhibStTh+xavBExKqw86EHAMsLEfMhOARjjgMOQTMtrDTPnH40fEk fCjwBd6yLSS8miIjhjCkqJG4Bcj7qjuePTqRXxnoWi658cviMIUd7zVdWmMk0z8Kg/idsdFU dh7AdhX6EePvh5eeD7t9O1i3huLa6Uokoj3W94uORg5wcZyhyRz1HJ4P4cfBjQPhVd6lPo9q 0Mmpyb3LtvMS9o0J5CA5OOvPJOBihEXhrw/oP7PHwxaMyrb6fp0Zmubhx89w/djjqxOAAPYC vkH41fF29+MfjKXUbgNDaRDyrO23ZWCPP6sepPc+wAH2t448DaZ8RfDk+latbi5tJ8HAJVkY dGUjoR/nIyK+XPip+x7q3w/0TVNWtdQtL7TrA+YFc+VMYscsc/KWB4wD83bn5aAPHaKK9L/Z r+BMvxf8UC4u0ePQdOcNcydPPbgiFT6kck9h7kUAdr+yF+z4dZuofFmswH7Jbtu0+B1/1zg8 TH/ZU9PUjPQc/S99YwanZy21zDHPbzqUkjkUMrqeoIPUU61to7K2jhhjSKGFQiIowqKBgAD0 Arzz9o346Q/B3wtstmjk1zUFK2kR58sdDKw9B2B6njscAHzh+0f4C0D4YfEGax0O8lnZkEkl u2GGnsTnZu7nHIB5UEck1ynw/wDiLq3wx8QR6lpFy0E68OhyY51/uOv8Q/l1GDzWTfX0+p3s tzcyyT3E7l5JHYszsTkkk9STUNAH3P8ABb9ofw5+0L4Qk0PWbVZHChprCRwJrdu81ux5IH6Z wRg88n8YPgNe/DZRqNnKdV8PXDfubxF+aLJ4SUfwt2z0PseB8peGrnUbTX7OTSXuk1JZV+zG 3z5u8nAC45yelfoJ8Nta1nw94OtV1+Syu7yW226nGYx9mmyPmDL06cEjAznGAcV8nxPwjhM4 p3n7tVbSW/o+6/Loz5/POHsPmULy92a2kvyfdf0jkf2c/wBrjUPhW8Oka0ZdS8OnCp/FPY+6 H+JPVD+GOQfsLw14m0/xjodtqWl3cN9Y3a74pomyrD09iDwQeQQQQCK+Ovi5+zvBNp82u+EI 5ZLWIF7zTCS81p1O6Pu6ce5Hvzjkvgn8e9b+COtiaxkNzp0zZurCRsRTjGMjrtf0YegzkcV+ PTrY3JsR9RzSOnSW913T6r8Vs+x8xlef4zJaywGaJun0lvZd0+sfLdfgfoBRXMfCn4uaL8Yf Da6jpFwHKAC4t3IE1qx/hde3Q4PQ4OK6evo4TjKKlF3TP1KhXp1qaq0pKUXs1szA+I/wy0b4 reHJNL1q0W5gfJjcfLLbvjh0b+Fh+R6EEZFfGvx8/Zg1r4LXkt1Gsmp+H2OY71F5hycBJQPu tkgZ+62RjByo+6aju7SLULSW3uIo54J0MckcihkkUjBUg8EEcYNefmOVUcZG01aS2a3/AOCv L7rHg59w1hszhefu1FtJb+j7r+kz8y6uadqi20ZguYFvLF3EjQMxTDDo6MPmSQdQ64Ir6N/a H/YlMX2rW/BkZZAPMm0kcsP7xgPf18s89dpPC1803FvJZ3EkM0bxSxMUdHUqyMDggg9CD2r4 HE4TFZdWUr2a2ktn/XY/FsxyvG5ViFGquVraS2fo/wBN+6Op8THTdbsJNUnuYLZ7m7ZEnjgZ IYVYAolzy2xi24CXhDgZwSBXgHxn/Zru7DW7zWvCtvbadrczmbUdMl/dWusE8mTI4jnPaUAh 84fPyunrem6nNpVwZIWALKUdWAZJFPVWB4KnuDXUWEuk694fjtEtktLTTLSRltoY5JrqN924 eT8x3xgFh5QGVAULxgD1cJio4iaq4d+zr9vsz+XR+XXfRn0XCvFePyjHwzPJqro4mPb4JrrG S2afVPR7qzVz4v0bWoPEcMgMF1Z3dnJsuLS6iMN1Yy4zskQ8qcHOeQykEFlIJv5CICzqCW2j JwT/AJ9vSvpST9mTwt8RtVPinWBtFlaPb2uo2krwtcxuMguBjzEQnKq4bDlsYy275p1SSOz8 Vapok8N1b3VhK6iO7iET3MG4hLhACwaNwMggnBypwyso+/hRxEKFKpio8kppvlbV9PLfs/mj /Sfwv8WMLxVhYUsVD2GM5bypt/Elo5Q1u1s2nrG6vdav3L9mL/goL4u/Zo8ay3GrrP4v8Gan 5SanZbFOpWIjTYs9o/BkIX78Ehw/3kZHLiX9GdOuvBH7Wnw00/X9E1K11rSrxGaw1SxfE1u2 drpyNyOrLteKReGTa65XA/G7zW087ZNzwDpITkxj0b2/2vTr0ye1/Z9/aB8Xfsn/ABDbxH4M uUktr6RW1rw/cyFNP15QNu5sAmG4CgBZ0GcKquJEAUXGrUjNVIStJdTzvEHwloZjGWOyeKhW 3cNoz9OkZfg3vZ6n6z/Cv4a6J4bs49L1bT7CXxBC8vl6h5GyS8jLFlaKTlkIQANGGBUqxwVI dtPxb8KvBEE66hrwRHkxCk9/q04Hc7FLyYHc4Hua5L9nL9pfwV+2X8M/7Y8O3ErNbukWpaXd fuNS0O5wGEUyKcxuPvK6MVYYeN2Uhj3raisFsNL1/F1ZXBWOK9cBQzbhtWXbgJJnG1xgFgMb W2g/cZRnlPENU66SqbJ9/wDJ+X3dj+UMZgq2Gqyo1ouMouzT0aa6NGd4O8DeH10lYPB2vy2l haSN5kVheRX0RkY5O8yiQqSSSdrKSSSck5rQj1e70iaG31i1Fu8riJLuEhrWdycKBk7o2bj5 XGNx2hnOCaPijwBq11PGbBNIuLm3U/YtUu3ZLzTWIxkBYyJQMsSNyB1Oxsgsx6HxB4h0ldSg 0TUGjkk1VGTyXjLxspBwHOMLuwwXdjcVYDJBror5VSxkJOvT9nO+6a18+l7+aTOdTcdncz9b jks57bU7eJ5rjTi26NPvzwsB5kY9TwrAd2jUZAJNeF/t5fBiHxT4btPH2ioJ3gijS+8hQwuL dseXPxyduQCeflI6BK9t0eWbQtXl0S8lkmkjUzWU8jZa5t8jgk8l4yQrE5JBRicuQCzeDw7L caZqMcU2h6vIyxmfDRRPKcNbyBuNkjE7c5BLlOPkDfO0sHTrUquR4/RS+F9n0a/NfNdTjzbL qWOw0qNTaS+59H8j5C/ZL/acb4Ha3JpuqCSbw1qcoebblnspMAeao7jAAZRyQARyMN9gTIlh CutaO66houoD7TNHbnzQN/zfaIcZ3A5yyD72dy/NkSfH/wC1n+zFJ8ENcXUtLEk3hnUZNsJY lnspDk+SxPUY5VjyQCDyMte/ZA/ajl+E2sx6Drc8knhm+f5HY5/s2Qn74/6ZsfvL2J3DncG+ dyTNJ5fWfDeer3VpCfa+2vZ9H0+F6bfDZFnNbLMR/ZOYu1vhl0t0Xo+j6bPy+w7a5jvbaOaG SOaGZQ6OjBldSMggjggjvXJfGX4fXvjTQbe80K4t9P8AFegy/bdGu5lJjEoGGglxyYJlzG4H IDBh86IRt3sC+EJ2voJEk0C9PmyENlbFm58wHp5LE5PZCd33SxTVrux2Cq4Gvyy+T6Nf1uj9 OjJSRy/ws+Itj8Y/A0WoraSWk6u1rqOm3QBn0y7jIEttKOm5G7jhhtZSVZSSuP8AizpurfBv xjN4/wDDGj32vQahGtr4i0KxC+fqBAC295CCQpnjO2N8n5oSMnMKAlZLDSn71LZ+aVvLVg5J aMzfjR+1j8Ov2dPjDa6dr9rPbaxqVgs0moWtmsohhaUgLIVO/koWwAxwo9Rnsvg5+0V4U+PE mqjw1qH21NJnELswCedlQwdATuKc4yQOQRVDxz+y74R+JXgW30vXdF0zU7+1sBaRajPCTcow TAbzFKyY3c4DDNeL/C/9gjQ/2TdVtPiHf69daxdeFrG4nmtDbqkU9wUZUaM5yo2tgBg3zEHI AxXlxUoq9kluz62X+r0ssnUrVZ069OL3XNGVru6trFaW1el07OzPJ/2g9VOs/G/xVOdpC6nN CCOhCMUB/Jan8C/GaTSbaDS/EVlH4m0KGaGWCK6dmudIeISBJ7GQnNvMglfa68844zXG6hfS anfz3Mp3S3EjSueuWY5P6moa/OKOb4nDY2WMwk3GV27rzb3XbyZ/IMczr08XLF0JOMm2/vd9 e57D+wN+zl8NP2f/AB7Yauni6DXLa6sk8JeE9DFk1l/ZUUkaG8ur20SVrd7+8kigSa5hijST ykO0GSUnovhl+1L8Q9e8N+CfGlreeC9R0r4hCx1jRfhva2Vw/iJPDd3dwwrqCXbXB824ghuY 7i4j8jyo1Bi3JgTt87Xl9rGkvBfaFfHTtVsJVubeYIrkOh3KBu4HzAcmt/wB4SX4i6QdT8Na SPBvxI8OXv2jQLKLXGfSrRbudY9Wm0ixvGewsdQltXuEhz+5Z7mXiISO5/auGeMsNmsPY5oo Kd7R89PPZvpb03P2jhrNPr2X/WqtamqnPyezTaqbXUuV7p66xulbWx90+Gvi2918Qr7wxqdn HDqdtKcfY5RcrAjb2hW425MLyRJ5i5+VlB5BBUdRqXhnTdZkD3mnWN24OQ00CSEcY7j0r4N/ ZM+L3jX9lPSvEq654X0uOzF3H4m8XR6xqJ0ceAND8pLOyjkLSXiy6nc+VLdmzjn8mNSwBjaa MSfYHwq/am8A/G7xTdaF4Y8Qf2jrmn2Q1C+0yWwurS90yFpPLQ3UM0aPbO7AlEmCPIqsyBlV mG2Y8P18JLnoNygtb9VZa3tbzdz6p4iFS1o8v5fK/wDmdDqXhqGyns0srjUbBp5hGPIvZVjj AVnOIyxj6JjlT1rkf2nf2bh+1H8FLzwLrHiG+XSNV1fSL3UBJEgNzZ2ep215PaAwiJlE8cDQ l8kqspPWvQJYxceIITkEWsLMQexcgKR+CuPxq7XDhc4xdCSlGbaXRttfmTKnF9D5Uj/Y+8ef CjwxoHhfwlHoF/4F+HPjHVPE3hLTYdXfTbpNOm0LUktdIdjCyQi31S9UQyDzFS3hgJUtGVPl Pwo+BPxI8IeBPAGk+OdG+LV3pGifE201IXHnzXeqXlpZaJeXMM91bQXt9DGz6nHaxPIJVgmk /eiKAuGb9AaVHZDlSVJ9Diveo8XSVlVp39GZuh2Z8ef8E/P2l/Gv7Q/xc8Tadr+uX3/CO6f4 U0fXd06WsU2kXuoXV6iWS+VZwRoUjtijwSm5eNgg80kndX8C/tseIPGX/BQDQ9DtNX125+E+ t32p+BtLN34WmSx1vUre0nvJdUXU/sqW8iLLZXNlFBDP83lyyFXEkbJ9nfapNuC7EZzzzXN6 18J/DHiLQNL0m80HTG03RJYZ9Ot4YhbpYPCrLGYvL2+XtV3A24ADEdCa1hnuWzn79K1+tl+m onSn3PlP4YftzeHvEnh5NR8Z6D4fit9a8M+H9W0WPS9Nm/tDVr7Wp9Ymt7FFjDtvXT7G2mbC 5USSSMQgwPTPh/4p+F3xH8A29/PrekaLqltpFtqutQQahNHDpXnXM9mwZ7xI2VUu7W6gIkSN w0DBo0b5as/Er/gnJ8MvHvhe006y0+fw++m31hf2EsccGpRWrWWlyaVBF9mvo54Hh+xTSxGN 0OfMLgiTDilY/wDBOPwro/i/4UT6bqrWHhn4a6e1pe6Gmk2sMXiqaK4ju7Ce5+zrFHGLa986 6EcUSo80in5QhV+fH5VwxmaaxFKm2+rik9PNr/hzWjicVR/hya9G/wBC94d8I+EPiD448Q+H NB17VRqvhafyNQS506Qxo2QoAl2rGxLEgKG3cZ245O5J+zLKqNs1uOR14wbQoM+hO8/yr448 XfsjfEj9mbwbqPjfx/4g8LxpDpGn6Fqt/oOpJYxawtz4isL3WS/lWFnDpsN7b280amWV44ZL yTfcoHaU/Q//AATh1DS/EnwN8SeJrnSdetfC3ivxtql/4S0y7uH1kaLpsAisYltXheeOK2ka 0lnjFvI0GLgmNmRlJ+dzHwg4Xrx9pTpRgvV2+9SX5ndTz/HRfxt/d+qOuf8AZv10EbbvSSO+ ZZB/7JVDUPgL4ktiVS0gu1I5Mc6AH/voivYbC00LVbpodK8S3cF03LRJqIuJR9Y5/MK/TAq3 qGla1osT3ENxBq1vD8xtzb+XdSL32uG2FgOg2KGPGVzkfL4vwNy3WdGGn92cv/br/mdVPibF rRyv6pfoeNfCn9leTTtRuLrWPNs7d3GLVJQzOBzglSQF6jOd3X7vU+yzXNj4U06CFUS3hB8q CCGMlpDgnaiLyxwCcAdAT0BNQnxRHqJhh0pV1G7uYxMiBtiRIeA8jY+Rc5GMFjg4U4OGX1xp 3w4/0/UrhdR1y5XajMVjIXIyqBjthhBIBYnk7QzMxXP0XC3BNHDwcoJxj9qctZStpv5fcu17 nHmOa18VPnrSu/wRwH7W/wAeF/Yu/ZW+Ifxn1PSItf1LwZ4dutTj0k3gsxOkKtMLVZtkm1mw AzhXBK5C4AFfHGr/APBaqL4y+A/ip4r8C+G9I1f4f/DnRDdeIvFk/iN4LOfVVt0uG0e0EVtN JJbwRSKJbraoZ3bZE4Y5+gf24dBt/wBr39m34kfDWXVjaXPjHSLrQF1CK3M1ro63EIDPHGSh ncBsbiVzzgqCUr448ff8EldG0vQvHFn4R8awfD7wl48+HS+DPE2kQaIj2FzPBB5Nvq6qJkEU 8cWUZRkOnBIb5q/T8NhqU4RjGDjCD0T6+bW+97X6622PJb8z1XXv+CkXwm8L6/daJe69evrd gFiuYrPRdQubOO7NqLr7GL1YPsxuPJYMITIJMEfKM4r4cv8A/gq74f8Ajf4NXxtqup69oGm+ JjdQrpq6fe3AgtrOQktIsMTARIpV2kb5FLtlshsZnxj/AGWIfHP7X8XxF03xJBZWWn3VvLH9 j0KLT9Tv44bdYfJuLmB0WeB9ucTwyShSE83Aqrpf/BHv4kjwJZeGLrXL298NJpep2CW8vh/z khtb9hIs6xC7RGvocyBXkDDDkeUp+avTIP0o+BvwQ0bTPh9bXOpCy8TXmtW8VxNd3CrcxvGU HlpGWB/dhSMHv14GAPSrCwg0qxhtbaGO3trdBHFFGoVI1AwFAHQAdq8/+BHjfw1o3w08O+G4 dftJb3QdOt9MkjulFlcu8MSxEmB2LKSVzgFgM4yetei0AFOhmktbmKeCWW3uLdxJFLG214mH cH8x6EEg5BIptFAHq3w4+L+nfFbQLfQvFdtam6v4kCuw2wXrEAjb3jlB5AB5IBUg/KvJfEv4 SX3w3ka4VpL/AEZm+W62jfbZPCygdvRwAD0IU43cVpMSy6QkMiq6R7oSpGQQrFce/SvUfhj8 dH0WFNL8RvLeaew8uO9kzJJEDxtmzy64438kfxZGWExeiGzzqor2yh1Kzlt7iKOeCdSkkbqG V1IwQQeoIr0r4lfAs6dC2reGEN3psqiVrGImRo1I+9BjO5Mc7Oo525GEHmO6e4ureWCaA2ZR vMUoS7k42lWzgY+bIIOcjpjmhHzz8TP2IXn8V2s3hmdIdLvJgtzDM+WsVJyXQnl1xwFPzZxy Rkj3nwN4K0/4eeF7TSNNiEVraJgE8tI3d2PdieT/AIcVrUMdoJOcD0GaAOM+NPxmt/gtotpf XWnXt/DdytDmAqFjYISoYk55IxwDxk9QAfi3x1421D4ieKbvV9SlMt1dvnA+7Gv8KKOygcD+ pya6z9o74t6n8TvHc8V3BdafZaY7Q29jMpR4vVnX++e/oMDtk+eUAFFFe4/sk/s+/wDCZakn iXWbfOk2b/6JDIOLuUH7xHdFP4E8diKANX9n34Na/wDDIWfiy48Nxa291Buit1uliu7FT/y0 COArMV7bgQDjrxWZ+07+00PHenroGipeWdkedQM6eXKzgn9yV5wFIBPPJ46Dn0L9qn9oaPwH osmhaNdI2uXqlZpI2ybGM5BOR0kPQDqBzxxn5KouB71+zX+2PffD26ttN1+5uJrGL5be+GXm tf8AZbP30/Ue4wB9AfEP4P6Z8a9O/t/wq1pFrVynnyWsLAW+pg8+ZE2cBj1x0Pt1PwLXr/7I /wASvE/h/wAeWulaWJr3S53ElzAd7LaKDzMhXJRh7DDHA64I8rOMmwmZ4d4bFxuuj6p90+j/ AD2ehwZlllDHUXQxEbrp3T7p/wBeZ3fg3xXr3wv8YR3WlTXWnatbv5LR7CGY5AMboRyCQPlI 6gd6+9dA1vxFb+FtG1LxBYWNjPfmGG6s4HZpLWSTCqcnhvmI3IB8gJO9tpzyPwl+GenePdds fH2tafaJNpiH7FdNlDd4AxcSD7pCDIVj15boEJ8F/a7/AGj774meOl07TZLmx0TQZ99qVZo3 uZQOLgjjH+x3AOeCxA/M3kWH4awFavjpupzO1NK69H5Pq+ll1bPlsFT/ANW8NUq16jmpStGK /rRvr6dT7Nor5s/Z2/bXjvvs+ieM5o4ZhiODVTwknYCb0P8Atjj1xyx+kYpUniWSNldHAZWU 5DA9CD6V52ExlLE0/aUXdfivJn2mVZxhswo+2w0r911T7Nf0n0HV4T+2f8I/Cl34KvPFF7IN J1qACOGaFQTqEn8MTrkbiQD8w+ZVGeQu2vb9U1O30XTbi8u5o7e1tY2lllc4WNFGSx9gBXwl +0j8c7j42+OHmjLx6Np5aLT4TwdueZGH958A+wAHbJ4M8xdGjhnGqlJy0Sffv8jw+NcywuHw Do1oqcp6RT6P+byt+enc87rofAPgybxHfi4laS2sbVgzyglC5HO1T29yOnbnpU8HeEpvGGq+ QhaO3i+aeUD7g9B/tHt6de2Dr/EHxZEsI0PShHDp1sNkpT/loQeUHsD1PVj7Zzw8N5NhsNhn nmbL91F+5HrOXT5X++zb0Tv+b5LltGhR/tXMF7i+GPWcv8vz66LW/qfi+x8R30emW72cOnxP HFGJ428iZQwDcqw2kL9w8qDyR0I80+NPwR0b4m2N3bRz3Am0eYmK5iHlaho8hOFfDD7jgdSD HIvBBHFX63fDHiaC11Wzl1GIzG0Uxw3AJEkKEEGNsEeZFkgmNiRkAjkCuLF8R/2piHVxz5Jf YlH7PZPuvP1YU+J8RUxsca5ulVg705wdnBrbzsfJmr6dqvw91uLSPEiQpcTnbZahCpW01TAy duf9XLgEmEknAJUuoJDRE1go8pS8IPKdSg/2fYenp06AH6o+KPws0P4gaPFo1/HY30mrWwne zjEkcNwykktayHBEiFQwCt5kfBBGBj5d8f8Ag7VfgVdSHVZJNR8KBsQawwJl08do7z0A6CcY U9HCHBf38HmM1JYfGK03s/szXdP9P+GP7z8H/H+lm7p5JxNJUsW9IVNoVu1ukZvtopP4bN8p 534n/aU8WfC39oPQdA+E95d6Z8Qb+CK51bVYJZYrfS9GW4Vm+0eWyiYyMjLHExI3bm+Ufe/V 3/gnD/wU/wDDf7fra/4cgs3OteE4/smo3aDzLDU5o0hW6MTbVXCyTBdo3D73PBFfkN+0H8BN M1e91XxtH4z1/wAASHSTaa/e6Y0ZW+0+ItIQwdG2SIGfbLGA4DEc8CvB/wBn79pbWvh78U/C F94N1NfCFtY67ZadoPgmO3e31HRNICCZ9bkmVw0TNFK0js4aKRGaN9+Tj6uGFjWo3p7pfj1v +nRLVu59R4hZHSx2IlSx0VGpNv2c1bRaKOiabWnv83NJydqcWo3j/Uja2V/4eBGm3Qmtl+5Y 3X+qjH92OQDegyf4t4AwqqoAAq+I5vD/AIh2HxHpj2MsG0pdyqVWLawYMtzGf3ah8EbmQkgH FfEv/BNL/gtp4L/au02y0DxRr2iLrMk/9n2HiG2cRadrs4dkEUiED7JdOy/Kjfu5sqYmy4iX 71rrw2f4zDP2dX3kukt/v3++5/NObZJiMBW9liI2b1TTTjJdJRktJJ90/wARPEuhp4v0KCWz uYluoSt1YXY+dFfHDcfeRlJVgDyrHBHBGfp95B4r0eaG6tlRxm3vbOXDmB9o3Rt2PDAg9GVl YZDAmKXw6+k3Ut9orRWV5K5klhORa3pJ+bzFHRm/56KNwIUneoKNI0a+LVbU9KK2WtWuILm3 uOA2OfJmC59cpIucbty7lYhvVxKo5xS9pQ92rDo+q9fyfR72ueUr03Z7FabR7TxfoN74P8SJ /aFtewssUkh+a8hBHJPUTRnbkjkkK45yF+G/j98DtR+BPjmXTbpXmsLjMthd4+W5iz+jr0Ze 3B6FSfundbeL7NoZBPZ31m4YpkLc2EuDhh1GcZweVdSfvKxBoeLPCWmfGjw1c+FfFdtGbsoZ YZohs344FxATnay5AZDnbnB3KwLeNmeWUs/wv1TEe5iad+Vvr5PyfXtuuqPneI+HqWY0bbSX wvt5Pyf4fg/B/wBiX9p2PSlg8D+I7gGznby9KuZmysRY4FsxP8JJ+XPQnb0KgfRSW7eDb6Ox kYtpk5C2UzH/AFLf8+7f+yN3HynkAv8ABnxv+COr/Azxg+l6mvnW82Xs7xFIivIweo9GGQGX OVJ7ggn6W/ZI/aWtPiv4eTwf4pnR9ahjEdtLK+06lGvIw3B85MA5B3HAYchiPO4ezOpiE+H8 5XLXh8Enu/K/XTZ7SXmrvxOGM7rUqv8AZeYaVI6Jvqu1+r7PqvPf3CiuY8DfETSte1XUNDh1 uw1TVNGlaKXy5VMkqDGHKjqRuCsRxvB6ZAormrU3TqSpveLafqtD9Cp1IzV4O/8An1XyOnrm fi98Nbf4s+Ar7RZ5pLd50LQSqSPKlAO0kfxLk8juM9DgjpqzvF/iSHwd4V1LVrhXeDTLaS6d V+8wRS2B7nGKynGLi1LYjExpypTjV+Fpp+jWv4H5y63oN14f8QXml3Me29sbh7WVFO7EiMVI GOvIqC9snsJzHIVJHOVOQR/n1qxrniG58Q+JLzVblla8vrl7qRgBjezFicemT0qTR9C1Hxnq ZjtIHuJmxvYDCoOmWPQDivyaGHlWr+xw0XJt2SV2320P5zhSwtSlOFJTdVzXIla3JaV79XK/ La2lua/Qza7j4Z/Ca88QzxX12ZLSwU5HJWScei+in1/L26zwv8I9K8Eae2paxLFcS2qGaR5D iCAKMk4PXA7n06Ctv4d/FLQ/ilpJu9GvUuFQ4kib5JoT/tKeRnsehr9g4X8NOVxxOb621UF/ 7c1+S07vdH3GQcFzjKOJxztbVRW/zf6L7+h1njEt8W/AQ8K65reoafY29xYX2nXcNvFcGxvL G9t721lkjcfvolmto96NyybgCpIYeOv8P/it8P8A49+FrHw5rHiu+1nxpqUupeJvGum+HmfS /FV3NbxCG8uVWJ4rS005bE6eNPuLhGeC8Escj3EW5vV60NH8cX3g5SbeSSSCZtklqZGEU+8b MMFPoeo5GM9q/YWlaz2P0pLsdN8Ef2xPBnxX8Hahr0F+luI9Ol8RT2qO97c2uliWSO1u5Vij /di5t447iOLl3Er7A4QsfXNP1G31ayjubWeG5t5hlJYnDo4zjgjg85H1FfB37RH7Imta/wDC DTtB+DWgfD7QvAPhm2hhtfCt/Dp6abod+87RS69dC4tJJblI7SbczxXNtcobaTY7tMdvoH7K P7SWv3+vfC/wLbWKXui+I9Ev4dHvYLxb3WLC10lhb/2jrkJ2RR/a5CNywFZY7iVIm8z948Xy 2ZcM0pxcsLpLtfT/AIBvCs/tH1vRWcdTu9HULq1oYQBzdW+6W2PXljjdGMDJLgKOm81cN6j2 JuIQblCm9PKIbzRjI2nODntzivisThK2HlyVotP+tn1OiMk9iWiuW+EXxP8A+Fq+F5L6TRNb 8PXlrO1pd2OqWxhmhlUAnaejoQwIdeCD2OQOprnTNq1GdKbp1FZrcKzvETzMtlBHNJbR3d0k M00YBdEIPAzwCzBVzzgMSOcEaJIUEkgAVg32px+MJ7Cz0qQXiC/hlnuYVMkFusMizMGcfLuJ RU2g7gZA2CAa78roOriqcVHmV1fTpfW5hUdosvaYJtE8UX+npNPLbRQQ3ULTOXePzGlVo9x5 ZQYgw3En5yM4AA0pZmmbcxyRxWdrFyJ/iEkEAKvb6aXumKnH7yXEGD0P+ruMgdOM4yMzafHN p2j26XdyLu5hiRJZ9ixG4kwFLBRwCzdFHcgCu/Oac44yeGoX5W0+VbXsui6ip25OZjtQ0u21 e3MN3bQXULdUljDqfwNZ/gy2Qa0k2iRCHRWjKTFW22sp5KmBBxuBPzOoCsDjLlRskuNLEthL qHiSe3sdMhXe1m0gESr/ANN3zh/TYPkySD5nBHnfxH+PFz4hR9P0Izadpy/I10Mx3E4/2BwY l9/vnP8ABjn38jySth5KvWk0/wCVP8/8jGrUT0R1PxG+MGm/D8XVhoMFjcavcSu9wYgohtpT jLzbeWkPB2/eOBkqCCfGr++udX1CW8vbia8u5zmSaUgs3txgADsAAB2AqGONYUCoqoq9ABgC lr6tHO0VLc7NZukBwrxxyY9TllJ/JVrL+KPgSP4l+BNR0WWaS3F7HhJEYjY4IZSQOq7gMjuK 1J2EetWxJwJIpF+pyhA/IN+tW6mL3RTPgHTpbz4U/ESF72xikvdDvAZbadcozI3Q+x6gj2Ir 66039qnwNqFpG51pYp2iWRoDbymRSwB2DC4ZgeMKTzXDftp/Bgaxpa+LdOhBurJRHqCqOZYu iyfVeh/2SOy157+xz490zwj8SGs9St7YNrCrBbXboC9vLk4UE8hXzg47hfeqEcP4ngvPFvxR uGvoprCbWtRLH7SnkmMSScE7sYAB78cV9NfEX49XPw0+LPh/wfpWnWl7bXMVvC4dmWSJnfYq gg44UA8jv1r0P4iaJpviDwVqdvq8ZfTjbu8+07WCKNxIPY8V8Iad4x1LSfEdrq1vdzC/sWU2 8spExi2jCj58ghRgAEYGKVgP0JqG+ujaQAqN0jsEQerE4/IdT7A147+yn8ftZ+LN7qen61HD NNZRLNHcxRiMEE7SrAcZPBGAOhr15yLjVUUE4tk3kdtzZA/QN+YpSYFTXtfsfh/4WutR1G4E NnZI000h6sScnA7kscADuQK+drf9vbVY9enebQtPn0ss3kxJI8VwB/DucllJ6Zwoo/bp8T6y 3iTT9JkSSHQliFxEQpCXM3IbJ6EqMYHbdnvXgNNID7n/AGUP+CiNrL4hTRdQtG060uZcQWbz +apLHOYpCFCuSTlGAVuxDE5+kvHHwu074n6Z/wAJF4WuLc3VwC8iD5Yr0g8hgcGOYHIJI68M OhX8hq+j/wBkz9u3V/hFrMFlrF009hJiNp5izK6gYCzAcnHGJB8y4AIZcrTA+j54JbS6mt54 Zbe4t38uWKRdrxt6EfQg+hBBGQQabXsD2/hr9pzwxFqWl3cdrq0EalZU2vJEGGVWQA4kiPJD A4PO1gc15V4k8OX3hPVX07VrUW9wQdvO+K5XpujbA3L68AjIyBmgDzD4w/ALQvjnpiXSSw2m pAfudRt1WTzAONr4I3r+OR2PUH5X+OHw1tfhP4+n0e01OPU440WTO3EkG7nY+ONwGDx1BB46 V9V+K9FPwL+F+uT+DtJuLi4lka5S2RzJHbMwAZ1Qn7q43bVB59B0+Q/BPg/Vfi545h0+1Mlx fajKZJp5MsEBOXlc+gzknuTjqRQB0H7PnwRuPjL4tEcgkh0exKvezgYJGeI1P95ufoMn0B+n /jH8T9M/Z/8Ah1GLWGCO4Mf2bTLNBhcgcEj+4vU+vA6mrekaVoP7N/wqYFxDYabH5k8xH7y6 lPGT6szYAHbgdBXx18Vvibf/ABZ8ZXOr3xKh/kt4QSVt4gflQfzJ7kk96AMTVtWudd1Oe8vJ pLi6uXMkkjnLOT3qtRRQBa0bRrrxDq1vY2MElzd3cgiiiQZZ2J4H/wBevv8A/Yw/ZQh0LTfs jgMqlJdau16zvjK2yHsADz3CkngupHnH7Ev7K97by299cQCPxBqsZMfmrldLt+NzsP7xBHHu q8ZY19cfELxXa/BbwhaeGdAJTUZoifNJDNboT887+sjtu254zk4IXaRAY/x5+IkOpbvC2lsi afaYjvzFgI5A4thj+FeN4HHATpvWvm6a48IfGzUNR0rTdWddV0pyhdG3Nx3TfkPHnIO3H4fK a5f9rP49L4I0c+F9Fnxql5Hi7lViWtYiD8uevmN69QOepBr5g0bWbvw9qkF9Y3E1pd2zb4pY mKuh9jXNi8HRxVJ0MRFSi90zHEYenXpulWipRe6Z9AeM/Cmp+Ab14r6FZIwC0csXCzKP7ueM +xIx/P1H9nf9rTU/hI0Om6kZdW8OMRiPdmWzB6mInquOdhOPQrk5434K/tH6V8Y9MTw74rS3 g1ZwEjlbCRXrdip42Sew4J6ddog8YfC278I2iXEAe5sFyhcDLQlTtIbHbI6/yr8O4j4NxeTV HjssblS3a3cV2a6x89112ufmOZ5HjMmq/Xsuk+Vb90u0l1Xn9+1z1b9rj9qGD4jQQ+HvDdzI +ilUmu7gBk+1sRuEeDg7F4Jz1YdPlBPhui6PP4g1SKztlLSzHrjIjHdj7D/AdSBUEMElzMkU SNJJIwVVUcsScAfnXdSGP4S+GdimKfW78YLAZWMc8/7q84z94+2ceRkmWyzevPMcxfLh6Wsn 00+yvXrbXXu0cOFp1c5xU8yzGVqUPifSy2iv16692Q+K9at/A2h/2DpUrC6YZurheHUkDPPZ mH/fIx04xxAAUAAAAU6SRpZXkdmd5GLsxOSxJyST3NNrx+JeIJ5piE4rlpQ0hHol/m+vyXQ8 fO84lj6ycVy046Rj2X+b/wCB0CiiivnDxS3Z6igtTaXcRu7B3WRofMaNkdTlZI3Uho5AejKQ a6HxfaaR4p0a5v7maygtp5Utkd1ZgQ0eCt2CCqZYECQnadwB55PJ1Z0zVJ9JuDJCwG5SjowD JIp6qwPBBHY162CzPkh9XxK56XbqvOL6M9DC47kSpVlzQ7dV5rszwD4ufs7ar8Fr25udAsbi +8OJ/wAfegLFvn0xTks9pjmSLv5HJAz5ZwFirxD9on4V6h+0v8MItG8N+JrbQdI11Wh1XULa HzLue02PiGJgQFBl2q4PVN44OQf0W0kaT4h0CKyitltobGKaV498ktxbgLuUWygMXQEMPK4w CAv3QD8+/Gf9mWWK6k8U+B309LrUnNxc26nbYa/yNz5H+puuCN+OT8sgOFZPssvzWeG5Zylz 0r+7O23ZTWtn5n9eeFvjx7DDRyDi6bq4Sfuxr3fNBbclVp3cWtOa/Mk3e6d1+dHxh1PxP+zL rd3qmqnwVFrOtaRaaallY6M8mh6boFpNtuGWNpEkuZ1a4RzFkbId5BYKcfp1/wAE6f8Agsbq Pwd03wz4L+Lt5Bd2N9p6XEUa6oup654eiDFTK43NNeWBA3CQbpogcfvFwIvnjVvD/h34u2D6 f4i8PWOoSaZcK1xpet2Ec0unzgZG6NwwVsHKuuQykMrFSCfmD4j/AAE8UfB/4l2PizWdX1nx XoGgamdW06CCea51PW9UmnmSzslVyyWkUayhHaLZG6bQUyCR9nGdLFQSk7S79+yX9efdn9E8 RcL0K2G57e3wlSzjJNP2ab5pVFLW97tpx91xXK1J+zif1AeHvEOn+LtBstV0q+tNT0zUoEub S7tZVmguYnUMkiOpKsrKQQQSCDTNS0Zpr6O+tJfsmowrtWUDKyryfLkH8SZJOOCCSQQSa/B3 /gmd/wAFI9S/YX+JSaTreq3HjOXxlqLPr1hY3KyaRa3cgZv7O0+USGOG6gSFysc2wTYkyyl9 6fuT8G/jP4a+P3gCy8T+FNTi1TSL4cOFaOWBwAWiljYB4pVyAyOAynqK437XC1VODs1s/wCu n5n878TcK1sqkpX56UtpWtZ2vyySbUZJa2u7rVNmtiHxwxkjLaT4i01QGU/OUBzgMOPNgYg4 PHfGx1O3M1m4uPEIh0c20tlr4feki/Mtjt4N0j8bkAOAOrltjBQXA2NX0SPVTFKsklteW2Tb 3MWBJCTjOM8FTgZUgg4GRwKt+HvFL3V0NO1FEt9URS3yKwgulH8cbH9UJLIeuVKu31uCxGFz OcJVly1Y9tOa39eq6HxsoygrLYofEPQfDXxKsZfCeu+VdG8QSCEkpIrDJVkYdH+ViADkgNwV zXxt8df2O/EXwn1UvYQza9otw+23nhj3SqScLHIg/jzgAjhuMYPyj64stLisjLoutRLLd30j T/aW4TUn6+YhzlZFCg7AcoFG0lVBq8+pPo1rJZa4keo6JMhja6mUP5SngpcKeGTH/LTGMffA wXPFneCwGcVXhMfF06kX7k+vlr2fbbs0zw844fw2Y017VWktpLdf5ryPzs0nV9V8Ca6Liznv dJ1K1LJvjLQzRZBBHYjgkYor7m+L/wAAtN8baKsd1p1zr9khBtnt5UXUrFcg7Y5ZDiSM91ds gEkFvlClfn1fgLO8NUdLCVG4d02vwVz4afB2aUJOGDr+5v8AE46+aV187noNVPEGj2/iHQb7 T7wE2l9byW8wB2nY6lW57cE03xB4hs/DGmtd3sywwqQo4yzseigDkn+gJ6A14746+Kt94y32 6D7Hp+7iJWy0g7bz39cDgZ74Br6zLMnr4yV46RW7f6d3/TP1itONnFq9+h4tq/7NNjpXja4i t9bXU9DiIaKWNCsknJyhPTj++uQwwRjPHbaNolp4fsEtrKCO3gToqjqfUnqT7nmmeI9cj8Na Be6hNHPNFZQtMyQxl5HCjOAB1NfOUP7dl5c+FNViuNLjg1eQMLCaA5ij3HA3hucqDnI4YjkC vtsm4cwGWJ/VKaTe73b+fReSsjwMuyTB4JuWHgk313fom9l/TJf2zfjkbu4fwfpko8qFlfUp UbIdhyIfoOC3vgcYOfCfCvizUvBOtw6jpV5NZXkB+WSM4yO6kdCp7g8GqV1dS3tzJNNI8s0z F3djlnYnJJPck1HXuHqn1t8Df2utN8e+VpuvmDSdYbCpKTttro+gJPyMf7p4PY5OK9eH+k6g T1S24+rkf0U/+Pe1fnXXsPwI/ax1H4cLBpWsrJqWhqdqt1uLQE/wk/eX/ZPPoRjFJoD65u7C x1nS7/TdVsLfVdI1ezn07UbGfPlXtrPE0U0LYIOHjdl455rJ+GXwt8K/A+58S3vg/T9UsNd8 aXkV5r2u3uqSXmraoYVKwRyXJCuUjBbAJyzO7sWd3ZtDR9Xttf0q2vrOUT2t3GssUgBAdSMg 4PI49a8u/at+OP8AwrHwp/Zmnyldc1dCI2U4NrDyGl+p5C++T/DgsD6a8HftEaroqrDq0S6v bjH75cRXKjvnA2OfQfJ7k9a7LQ/GPhHxzeFrO8bSNWuSMrn7LNI56cH93Mwz/tgZr8zfgf8A tY6r8NhDp2rCXV9EX5QC2bi2H+wx6qP7p/Aivqfwf410f4k+H0vtLuoL+zmG1h1KHurqeVPs R+lRUpxnFxmrrs9Rp2PqW403WdKcmP7NqtsO3+ouQAP+/bsT/wBcxVDV/GUVjGtuFkttTuJY 7aC3uYmDNI7qm4Af6xFLZZkJAUE5AGa8a8L/ABC1vwa6DT9RnWBMf6NOTNb4/uhWPyD/AHCt eieF/wBpu1kPl67YyWO0D/SbUNcRMfdAPMXJ6ABwO5GK8Kvw3g5zU4px11S2f9eRoq0kdDr+ i+G9DuYJPEN8dRu5Vd4La7lMouNpXPlWi/LIyllAKxs43AZJbm1N4h1vUofL07T7TSIwMLLf nznXH/TCJgCCP+mqkenasf4geNNC8I6enjWbxBp8emyRC3PnSGVJ408yRktVjDO9wcOfLRXa QxBNuQCvA/tDftg2nwYfxHY2eieIr+Xw5oMGu6vr1tYwXel+FLS6a5jgvruJrmGeeJGtZpZI 7YO6xRMx25XKxX12FVYbBQUIfzWXz02+WrYR5bc0mW/ix+074Y/Z38aWvhzVzqmt+OPFujan reiafaiJrnxFLYQ+a2nWyb9wndAxhjKhWEcp3MyvXyf8afjpe/tO2Mtz4u8Da3fad4a8OzXu oaNBJquhx6a9zeR/2b4gsnvre2meS1nspEZ3gjljyJ4FIMiN0Wnfs8eN/i/8Kxd+I/F0vhnx Br9vpvh3xrd+INIaTWdM1vR53ca1od1AscbB95kgYx+SuYZNqt50D+neLPFvg74D22vah4d0 /Q/Bml6lftqWo3mn2EVjda1eNktcTmJVMkru0jcAZLk4zmvTwuX0qL57Xm1rLq31flfsRKbZ p/BbUvGvxI/Y00TxZ49guNR8WS26W2oyGCaztJo7O4uoo9YtrOVFktzeQlJ2RwrLHKqkfuwD zPi7x5o/gLTUvNY1G2sLeVwiNI3MjEjhQOT1ycDgcnAGaX9jH/goFZeOvine+E9WWe0stVmM mk3F1MXkaU8sj56bzlgAThieuSR5b/wU4/ZX1H4feK4vGelvdXfhe+2wNASzLo8naNf7sTHJ XGACSPTPaiTP+KX7bVj4d1NLXw3ZxausbkTXMrFIWxwVjxyf948emQc1naT+35bvtW/8NTR/ 3mgvA/5KyD+deb/sz/BWH4u+Jbo6kbqHRrCLzJnjQhZXyMR7+inBz3OAemcjX/aa+BegfDHS dOv/AA/cXVxHcTNFcK8yzJH8oKnIA25w3XOfwpgfT9t4o0/xJp1hf2F3BdQsYrhdjgny5MoG I6jqevdSOxrtbjw/BqekC80syuYFAurdyDJGcffGOqn/AD6D86vhj8R734Y+J0v7Ri0UqGC6 hz8txC33k9j3B7ED6V92/DT4gp4g8P6br2k3QZLqEOHToD0ZCPUEEEeoqUtRlq5to722khmj SWGZSjowyrqRggjuCK+Iv2gfhFN8GvH8ltD5h0y7zcafLkk7M8oT/eQ8fTB71+gV5pcHi6zk vtPRILuFS1zaDgNj+NP6j/J8p+PHwmh+MHgGfT8Il/AfPspT/BKB90n+6w4P4HsKoR4P8LvG PxC+P0+paWfEMFvpH2PyNRaWGNisLIUJVcb2ZgDkgjk8kcCvErhBHcSKodVViAHGGAz3966z 4c+LNX+B/jyz1drS6gEMr288UiFBcICBLHk8Eg4+jBTX2aujeG/inoNtqMunaZq1pqEKyxyT 26SEqRxyRkEdPUEe1AHkv7BnhoWng/W9XZAHvbpbZSRztjXPHsTJ/wCO+1ep+LfFV54N8H6l q9ppVzrdxHO7G1gcK21W2ZHBOAq5wATnt3Gt4V8I6b4I0hdP0m0jsrNHZxEhJALHJPJPeptH yIZlIxsnk/Vi39al7oZ8M/GD4t6j8YvFb6lejyIYx5dtaq5ZLZPQdMk9Scc+wAA5SvVvi78B 9fj+LWsieXTVtZI5dZuNQkkFvZWNqXkO+Z2AWPaEYnr0J55NfPGu/tv/ALLvhHU5tPvfjkmq 3VscXFx4e8Lajq9hbe5uIYyjjv8AITwPcV8pm/G+UZdiHg605TqpJuFKlVrSins5RpQm4J9O a1+lzro4GtUjzpJLu2kn6Xav8jsaK0PBw8M/Gb4f3Xi34Z+NfDnxI8NWDKt5c6PMTcacWBIF xbtiSHIBPzDoCegrPzXqZLxBl+bUZVsvqqai+WSs4yjLflnGSUoSs0+WSTs07amNfD1KL5ai tf7n6NaP5Hp/7O/7UOu/ATXbZ7e5uJNOiY/u0YGSAMcsY88YJAJRvlbHIBww/Rj4PftAeE/2 p/BsFpfmyknuG+RVZlSSQDqhPzRSgHOwncATgsuTX5MV0Xw2+KGrfCvXPtulzKBJgT28gLQ3 AByAw9QeQRgg9CK9kxP0f+Inwn1L4bSNNI76hpLN8l4qYaEHoswHCntvGFP+ySFPA+H/AIe6 L4U1vUNR07Tra0vNUIa5kjQLvI/lk8nHU8nmuv8A2U/227L4meE9urmea1hxBPJMpkns2I+7 L182MjOJB83TcD8zL23xO/Z8k0zzdS8Nq0luDul0sLkqO7QMTwB18sg99pGAhAPLNT0u21rT 5rS8t4bq1uFKSRSoHR1PYg9a+bvif+x/p+m+EdX8Q6VqM1vHEhvILSSMuiRDcxTIBYkrtxxx gg8fMPpdHDgkZ4JUgjBUg4II7EHgg9CKq6H8uniMdIZJIgPRVchR+QFS3qM/O6vUf2R/h5de Ofi/p8semDU7XT33vGejSkERKo6Ft+CASAApJIANe3fEL9kLw34t8XW+sROdKt/N83UbeIbY rhRySvI8sk9SOMZOAeT9Pfs3fBHQfgJ4MuPENxZwaRARJcQRMpzaxueWIPzGV+AB1VdqAAlg aEdJp1vZ/s6/Dp7m6WO713USAyxk/wCkTYJWIE9IkBPPHG5sbm2n5b/aB/aLtPh/o+oahJfW 2qeJtQlaMRqyk+cFGS4GdiopXCnttHvXcfHz46w2NteeKNdZre2t1MNnZhgWUHJWJexkfGWP t12oMfnv4k1pvEfiG/1Fokga/uJLgxoSVQuxYgEkk9e9AEOp6nca1qVxeXcz3F1dSNLLI5y0 jMckn3JqCilVS7AAEk8ADkmgC1oeiXfiXWLawsYJLi7u5BFFGgyWY/569hX3P8L9Eu/B3gZN M1vUW1G5sEzcXE7AqQyBm5PVQSwy3JC5PWuD/ZS/Z9Hw90hNe1aEjXL+P91G45soiOmOzsOv oMDjnPb67qCanqd3JIdum2+yNjjJuXRiQAByVDMRjqzADGB80y6BY55ND07wvqF1rVtYTvNc krYWaqWk5BJ2rjKlgCT3VfTkVX0T4L6p4r1B9Q16cWrTnc0afNJjso6hQB06n15rvfCuhyxy NqF9GEvJgVjiOD9ljJ+7kcbjgFiO+ByFBO3XhYvhvBYiMKNSNqUW3yLSLbd7yS3t0Wi7p6W8 fE5Hhq0Y0ZK1OLvyrRN93bf0++55frf7Ov3m07UCcdI7hf8A2Zf/AImuO1z4Y654f3NNYSyR KceZD+8X68cgfUCvoGivnsx8NsnxN5Uk6T/uvT7nf8LHjY3gjL62tK9N+Tuvud/waPl+ivTf jJ8LRAZdY06PEZ+a5hUfdPdx7eo7dfWvMq/Dc/yLE5TinhsQvNPpJd1+q6M/Lc1yutgK7oVl 6Po13X9aBRRRXinnDopXglV42ZHQhlZTgqR3BrotB1e0vTfB7a1XUtQUBxNM0NnePuXMkgUE JNtBUSgZORnOBXN0V24HMKuFk3DVPdPZrs0dOFxdShJuOz3XRrszA+P/AOzRo3xF1C8vdKvW tNf0Ldax6nDEftWn5O4RXER2+dAx5Ab5WyWRlbDDwCW41Lwv4gGh+JLIaZq7bjbup3WuqIp5 lt378YLRth0zyCMM3114b8RW8Wp2L6iszfYiFiuYjiaOPPzRN/fhYdUbOOCMMARn/Fz4L6H8 U/DcOl6pbadM+qBrmGygnkIYxudsttNtVllUYbapDoTwcV9bl+N5Y+0wV5Q+1B6yj3ce66/1 c/oHwn8acy4UmqNO9fBP46Ld5U+8qT/Fx+F9bN8x+YnxC/Yv0n4K2niTxz4Ws9T1vVdB0K8j 8KaJBaJJJpl7O0rNLGyASSkNKNgfcYxv2k5AX3T/AIJ8fHj40/s4mw1uzhTwzHYWFlYLpura g9/P4jihjCyNqSKTGkj/AHkkjYzREnJZS8bdL458K6t8Cb3ytduZNT8OSyCO11x41Rrcs2Fh vAuFVskBZgFRycEI20Pn2fhG00bxLqmtWqXLX2rJCl0rXMjxuIgwTYjNsjOHOdoG7jPPNfZU c0ji6HMnzX69fTy630vr53P7h4Zw/DXEuBjmGTSVTCVE1Onokn15k05KcfdSjePLFRcXZRT/ AF0/Y/8A25/CH7X+hSx6cX0LxdpsYfVfDd9KpvLMZx5sZHE9ux+7MgwfusEcMi+w6tpFvrdp 5NwhZVYOjKxV4mHR1Ycqw7Ec1+HthfXWn6xZaxo2p6hoeu6TJ5ljqdhL5N5YSEDO1vQjAZGB R1JV1ZSQfvn9ij/gqxaePr/TPBXxaOn+HfF95ItpputwgxaR4ikOAiHJP2W6Y8eS5KOceW5L eWuSbi1KLs0fjfH3hPicpcsblqdTD7tbygvPuvNarr3Pr5bxL5F0TxEqzi4IFrermIXDA5XL LjypweRtIyRuTByqr9ruPDF5FZ6nIZYZmEdtfkBVmYn5Y5AOFk7ZACuemCdovX9jDqdnLb3E STQTLtdGGQwrPGqHQYGsNaAv9FmQoLudRJ5S/wDPO4z1XHSQ8YGHwRuf6rD42hmVNYbGaVF8 Mu/9duvqfiri4O8dhYNNvPDMpfRjbm2b72nzuY4M/wB6NgGMR7kBSpx0UksSlvre78ElAsV7 qekngNGrT3Np6KVGXlTtuGXHG7cMspUyr5xg37BJyS2dr6ev+Y0qctTwXxT4x1fxTqRuL5o7 lF4jjizGIgeyqSRngZORn8AK8i/aX+OyfC/wY1vYu6a7qimO3UqVa3XGGmIPp0HYt6gGvQPF /iuy8D+Gr3VtQlEVpYxmRz3b0UepJwAPU18KfE34hXvxQ8Z3ms3xxJctiOMHKwRjhUHsB+Zy epr7mlSjTioQVkuhzNnonwO/a31P4ftFp2umfV9HHyq5bdcWo/2SfvqP7pP0PavRfiH+z54Y +P2ht4j8HXlrbX843Zj+W3uG7iRMZjf3wPcHrXyvXQfDr4n618LNbF9o920DniWJvmhnHo69 /r1HYitBFLxb4Q1LwLrs2m6taS2V7B95HwcjswI4YH1BIrMrU8Z+ML/x74mvNX1KXzbu9fex GQqDsqg9FAwAPQVl0AFd98JfgL4o+I0dvquk20KWcN2kfnzlNoIIJcI3Dqvcc56YPOMX4U/D i6+KXjCDTLcOkKqZ7qYDPkQr95vr0AHckV+qvgL4L+B/gt8J9AsdU0bQiII7e1luJbQXKtcS EL99lYhDI3BOAAeSOtAHgnjrxvZ/C/wRcatqcoeOyiAwAEa4kxgKo6ZY9u30FfDPjzxtffET xXeaxqLh7m8fcQM7Y1HCovoAMCvsb/gp/wDs8alpGn6drGiPcN4ehZ3ksRykEuCWK98BQSAc 4XzMbVXB+IaACup+D3i3WfCnj7TTot7LaXF7cxWzquCkwZwNrKeCOe/TqMHmuWr1r9mH4Ha3 4u8aaTr5tvs2jaZdx3JnmyonKNuAjGPm5A56DnnPFJgfYVNu7q10rSb7Ub+8t9P03TIDc3V1 OW2QoCAOFBZmZiqqiBmZmVVBJArC+MPxT0j4FfC3xH4p1VBq03h7RZ9cTQLG+hj1TUbeJgsk qRtudYYxvd5djKqROT0zXlf7TvxG8Y/DXW9V1S/i8eappmmX8c8egaXpkV14P1Hwu8NrONVs b9oBCdXtLtY5YDPL9oluYxFHCIriJlLgafjiaP8Aa48b+GNB8HeKm8F2ukG41zwp4haC/sLy 98a6cLmC60e/hlENxYpHZSyiW2Ea3F3bSvJHJGts4fd8A/sk29nq18ni3wH4h0XwlqfhOC/t 9KTxJPBbaMLq4k+1+E7p7SUQ6lpyTPLcW8bb1hjuLiHbFDIqP2fwL/Z80j9iHSda0u0u/wC3 PGuqrYjU9cjtfsFmfstusMDxWZklRZjCz+bcMzTyySuzSFRGiV9O8T2HjzRtQGh6tBK0RktT c25WX7PLt64PBIyD6H6UwMv9ov8AaltPAcbz6pctqOsSqTaadG5AQfqI06e5xwDzXxn8S/in rPxa8QNfarcNJgkQW6ZENupP3UX8uep7k1T8e2l1Z+NtTgu9QTV7qO5ZXvEl84XJz94Nk5z+ nSvoz9jL9l6/k87xDrGgvJcrsbT1mzvgHOXKEYBORt3cjGQBwaAPmKyuJNOvoZleWGSJw4de GXB6j3r9VPgF8SNE/aS+EI8N6/OmvW+p2O1ZLgAPqUHRtwHSaNsBsc5AYc7sfLP7dfwajsPA dvrsul3FtqNjKIxJFENrROxLeZjoAxyDyQX6fMSPnT4Q/GDWvgv470zXtIupYrjTJCypuOxl b7646YYcH175HFAH6jeCvgJ4N/Z48Nw3OpT2r2uncW4lhEcEZHzArEMl5TjOfmJIyoHNWPjd oWj/ALQ37MuuSX+nXsFnNZT3dut1EI7hDCWKSDk4D7AQQeUcHjNWvBHxM8F/Hz4S6L45ulsJ bK0HnEzkMbGcEBoyOpbft2qRlj5ZAztri/id8arv4gq9jYxy2GiH74cbbi9/3sH5I/8AY6tx uxylID81PiV8M9Q+Gvjq50O5jeaaNs27opP2mMn5HUD19OxBHavoj9ifQdZ8NaDrFtqtpq1j FK8dxbxXKbIiGBBZVPzAnaM9iAK9qfS7aTUkvGt4Gu4ozEkxQGRUJBKhuoBIHHtSXeYLmGYE Bc+U/wBGIwf++sfmaGwNLR9Wm0PUobqBiskTZ9mHcH2IrU8X6NE0UWrWKn7DfHJXvBJ3U/jn H/6qh0Lwv9ttje3shs9OjPMhHzS/7KDua0rLxdZ3ch0o262ujTjyxxmRWJGJGPrkCmBxOo+H rDV7q1nu7K1uZrFzJbvJGGaFiMFlz0J9RWT4g8ZeGvhFo9pDe3Vho1mWWG3hVQgGTj5UUcKM 5JxgdTXVa5pc+hX09tIoaWHpzgP6EH0NfCn7QnxF1L4jfEW5l1TTodKuNOzZi3Xl4wrE4dv4 jknnAHoKAPqzwx+0L4X8Y+Pn8Pabfi5uljZ0mAxBOy/eRGP3iBk8cEA4JxXWaaNtzfKOgn/n Gh/rX576Rq1zoOqW97ZzSW13ayCWKVDhkYHIIr7F/ZV8c3PjX4cxzX+orqN+HYTOVIkUrhdr +p27DnjO7uc1E20roaPmP9pTw7df8FKv+ChuofAPULy6tfgv8HtJsNe8fWllO8EvifU7zdJY 6ZO6EEWyxDzioILHcOoRl+mNU+L3wk/ZB1vwD8MYJvDvhG+8X3Y0zw14c0y1SFpTsZtywRD5 IgIyDIQF3YGckCvkj9j79oPQfht/wXo/av8Ahhql1DZ6t47h8O6vo3muF+1SWukRNPCpP3nK XIkCj+GKQ9q+p/2r/wBma/8Ajp47+DuuaN/Ydrc+APHln4k1We73JPc2MFjqMHkxMiMWcSXq sqOVTBkO4Hhv8mPEHH1sbnGHw+e1Jxw9XD08RGzsp1a9BVZVHdNNus3C9m1CMaaaUVb9ay6n GFGUqCTkpOPooysl/wCA6+rv1Pn3/gpp+yjD+zZpV/8AtR/BbTLLwx8SPh1EdT8S2NlF5Gn+ ONFQ5vba+hTCu6xbpFlxvHl9chGTnfiBeaLqGt6XrPhw48NeM9Hs/E2jDp/ol3EJEAwTwCWH B7V7v/wV7+PWmfAf/gnx8SGu2WbV/GWkXHhHQbBcNNqeo6hE9tDFGnVyPMaQgfwRse1fK2ra NJ8KW+Gvw0lnjuNQ+F/gDRfDWqyRurob2KDdMAQSMAuBjJxjrX779FjOM1xFWj9YlKSftqd3 duVKnGnJXb3VGpNRg38KrTinZWXgcVUaUVLlVtn83dfild+iZuUU+GF7iZI41LvIwVQOpJ6C vqv9jL9g/U/E/wATmufE0MUVlo7JKyLIHHOCGyOjHBVQehVm/hUN/dp8Gesf8E0f2Wb3wn4W m8T+I0aKK9lS4tbSTgBkB2uw/wBkk9f4gOhTn2DWf2k7yHxo82n28N54fgPlCLgS3Y7zI+cA k/dU8EDJI3fLD+0v8QG0zwrd+E/DzJbG3smS4aIKEhUR/u7dR0GRgsDwFwMEMcfmdqfx88aa uMTeJtYUcjEVwYQf++MUAfqf4o+H+i/GrS213w7c28GqMNsjEFUmYD7k6gZVwON2NwGOGUAV 4uNMu9B1rUrC/tZrK7gmDNDIOQGRfmBHDKWD4YEg4NVfhX8SdR0LRtL1vS5JUu57KFp2mBS3 uAUBxIGxvHJwwyRk4Iyc+7aVqnhr9pLQYYL2I2mr2yeZsimAuIVOAzRSAfPE2RzjuuQrYxO7 Gcj8CfhsfGmtLrF4mdH02UiJCOLydT/6BGRz6uMdFYGv8Y/ig3xA1n7JZSE6HYP+7KnK3sg/ 5a+6DkL2P3uflI6n9oLxLN4U0LT/AA3plq1hp97F5ckyLsj8pQR9njI6MQPm/wBjOM5JXyZQ FAAAAHAA7VQj46/a88Y67r/xLlsdUtJ9OsNOytjAxysqE/67I4JbHbpjHUGvKK+/fiN8M9I+ Kfh99O1e2WaPrFKvEtu395G7H9D0ORXx9+0T4L8PeAPiJLpnh66uJ4oEAuY5CHFvL3QP1bjB II4Jxk9AAcHX0B+yJ+z0NZnh8Wa3AGs4mzp9vIv+ucH/AFxH90HOB3Iz0Azxn7NPwIk+L3if 7TeI6aDprg3Lcj7Q3UQqffjJ7A+pFfW+vaoPD9hBZafHCt06iO3ix8kKDALkD+FR27nA4zkA EXiXWTcTvptu7KwUG6lXjykI+4D2dh+IU54yueM1b4seG/Auu6Qur3aW1vecWMaplI1AwLh8 fdQnCp26t0AKw/ETx1p/w58LXN3dl5raFypUsN+p3B5MXuOdzsBgD5RnkD5K8U+Kb7xlrc2o ahM09zNgZ6KigYVVHZQOAKSA/QmCdLmFJYnSSORQyspyrAjIII6g06vjP4D/ALTWp/CKaOxu xJqWgM3zW+R5lvk8tGT+e08H2JzXSfGf9s2/8Tebp/hdZdMsGBV7twBczf7uDhB/497jpTA9 o+K37Sfhv4UXC2tzM99qJcB7W2wzwrkZZz0XA7dT6Y5HPfFj9sLQfBumpHobxa5qdxGsiBSf s8AYZBdh1PP3Rz2JWvkaSVppGd2Z3c5Zickn1NNoA+0v2a/jePjN4Smjv/JXWdPOy6RQFWVG ztkA9COCOxHoRWP8XfhZ/wAI7K2pafGTYyH95GOfIY9x/sn9K+bvg1471H4d/EPT9Q02Ka5l aQQyW0SF2uo2I3RgDqT29wK+7ikeo2W2WLdFOmGjkXqCOQQf5V4PEXD+HzfCPD11ZrWMusX/ AJPquvrZrx86yajmNB0qmkls+qf+XdHzJRXX/FP4ZyeC7wXNsGk02dsIephb+6f6GuQr+Ys1 yrEZdipYTEq0o/c10a7p/wDD6n4bjsFWwlaVCurSX9XXkFFFFeccoVcsdTWO2a0u4ReWEjh2 hLFSjg8SRsOY5FPIdcEGqdFa0MRUo1FVpStJbNGlKtOnNTpuzR1HivQdJ8a+GrqW8ksWsWhh s3mvXV2vmkzG6XMYQIuTgbh8rbjkAdPlv4p/BDVPgPdzz6ba3+o+F4STcWXzTXmhjrmMctNb 4/hGXjH3d6ECP6E03U5dLnZ49jLIpjkjkUPHMhGCjKeGUjgg10ei6Tpus+HYbO3NxsgaR2e5 uVLaREI9wVdw3SQbgRyxZNw/h6fV5fj/AG0nVw9o1usfszXl2l+fTsfqHh/4iZpw5j/7Qyif LN/HTf8ADqxXRq+kuzWqb06p/GgeLXrKG/0y8hcTRhobiNvNhmQ8jIBwy+hByMnBGTmCK/tf EkU+lanZxJPJGVns5wJI506FlyMSRnI5xkZAYKTivS/jL+zXfeFNRn17wZFbzm9JvLrSUnUW mqhssZ7WTO2OVic4yI5Cfm2MTJXlxOlfEvR3UGYPaTtG2Q9veabcKCrAg4eKVckEEA4Ygghu fq8Dj6eJi+XSS3T3TP8ASHw58UMo4xwTr4B8laH8SlJ+/B/rHtJKz2aTul9TfsSf8FF/EP7N d3pvhPxtdah4p+HLP5MOpTyNcap4Xjx8oLHL3VouANpzNGD8pkUBF/TLw94i07xl4estV0m+ s9V0rVIEubS7tZlmt7qF1DJIjqSroykEEEgg1+Gujm9tIzb38kc7odsdyo2+eMdWXor+uPlP UYztX279j/8Abh179jDVpbd7W98RfDu+ma41DRbcB7rTpGOXurEEgEsSWkgJCyHLrtkLeb2S j2PjPEXwnhioyzPI4KNTeVNaKXdx6KXls+mu/wCqtkl34LJFjDNf6ax4sVZFktf+uJYquzP8 DMAoPykABCVV+GPxS8PfGfwRY+JPCur2WuaJqKloLu2fcpIJVkYHlHVgVZGAZGUqwBBFFe3h +JMZRgqejt3Tv+aP5fq4blm4zTTWjW1n6Hzh408Fab8QfD0+l6tbLdWc/JUkhkYdGUjkEetf KHxw/ZU1b4YedqGmmTVtCU5MgGZ7Yf8ATRR1H+0vHHIXivs/xB4fv/COrtp+qW4trwAsoVt0 cyg43xtgbl5HYEZAIB4qpX6UcJ+cdFfV3x0/Y/sfGAm1Pw0sGmaocs9r9y2uT7Y+4x9funuB ya+X/EXhu/8ACWrzWGp2k9leQHDxSrtYe/uD2I4NAFGiivf/ANkT9ny28T20viTXrNLixcNB ZW0yBknyMNKQeoHIHvk9hQB5l8BviAnw4+Jen39zf31hpxfbeG2UOZY/7rKeq5xnGSBkjnFf pL8H/jt4W8VfDKy0XWFtNQ0QW6WsF0EFzaTwoAEWUclXXABJGMrklTwPiz4rfsSXUWtxT+E5 VksLqZUktriTDWYJALBj99B1x94AfxV778OvAdl8NPB9lo1go8m0TDSEANM5+87e5PPtwOgp AfT2sv4Y+Mfh2+0GDVtM1EvBuzbXMdxJbnosoGTkq2OuQehyDg/l9+1p+zRqHwJ+JM1rHZuL C9n226RguEduVRepKsOU74yp+ZGr7G0nWLvw5q9tqOnyiK9s23xk52OO6OB1RhwR+IwQCPWf FWhWH7Q3gK11jTI44ta04sEjlxujkC/PbuT0ByCG91YZViGLAfB/wG/Y3EiQav4vjcHIeLTM 4+hlI/8AQB+Pda7T9pzxH8TfCHjXwb4f+H7aj4YsvG+kLa+Ar/TDaafYP4hiWaWca3dXUcrL YLbRLNBBaRlrlBcrhikbD6u8EfA+08OWR1rxfLbxx248wWjyL9ng54MrdHbp8v3QT/GcEcr8 f/GWg/H3QLnwxrPhfRPEng64eOSey1uzFxFfvFIssTtE3CqrorANySBuC4KlgfPvwl8G6n+0 bDbfELULbwJ4c0PxZ48g8YLqEE82oaxps2j3EdhJFpd0tuiXumahb6eBFPIID9l1GdfLlVhj 6l0L4NeDNb+DnhVfBPhrw9bN4Ccv4ctbywhun0CQfeggaUMbYgEBTGyhVEYH7vArzvU9Vn1e 5864fewUIoACrGoGAqqOFUDgAAAVqfDnx9P8NvEgvUEkthc4S+t1GTIg6SKP76ZJGPvDK9dp UA+Yv26fH3jH7XCr3EsOhanlZ5UBSaWcZDxTHquAD8nA4Oc4wPBfh9resJqP9iabqF5ZQeIJ YrS5SBwpmBbAHJAz8xHUZyRnBNfpp+1Z8D9L+J/gu51eGNLvS9Tt1e+8ogjZtBju4z2KjBJ6 bQG4Ctu/Mv4mfDzUPhR40udIvs+bbkPDMoIWeM/dkX64/AgjtSA+1vgx+yt4N0HVdOI02KaT R0e4e9n+aZzxliemcgY4+XnGDk132r+MZ7uNLezX+z7KL7sURIJ92I6mvnf9kP8AbKuNT8Yw +GPFstrFZ6vajT4r8Aq/nchTKSSPmyBkAc49cj3vWtDuNA1Bra4Qhx90jlXHYj1FAGnpljH8 RvDWoaBqQ+1pLEzxrMDIGGMPGR6MDXzr8Nv+Cfttd/EK/n1C5N1oVtLvtoCSmE6/v27Y5XC8 tjPHSvopYbP4caO2ua7O1mIPnSMyiLaoGS7tn5VrE0/44xfGTQ/t2mX0M+mySNGRApQFlOMM D82eh57EHHNAF3UYdG0W0gsNH0+yWO0jEQu/s6iUrjG1DjKJ7D/9edRVjTNLn1i8W3to2klf sOgHqfQU0gIFBYgAEk8ADvW9FoFn4etFn1hBPNKuY7ANhiD0MnoPb/64qSS+svBMZS0eK91M D57kgGK39Qmep9//ANVfNP7Qf7Y8Whz3Om+G501HVSSs9+37yKA9CF/vuPXlR79AgPd7zxdL 4omZ7mWAS2o8t4YyFS3x2C9gcZGeSMVyXg74yaD4+8W6lo+k3TXk2lxq8syLmB8nBCv/ABYO OehzwTzXxz4J/wCEu+ImvX+naRc6jd3WvYF+fOIE6g53Ssf4Rk9fUjvivq/9n34Fx/BLw/cR PeyXuoagVe5YEiFSucBF9sn5jyfbpQgPZFA8ZeG9oG7U9KTj1nhHb3K/5618p/tqfBb7TAvi /TYAZIgItSRByy8BJvw4U+209ia+kdI1WXRdRiuYTh4mzjsw7g+xq1498NWl/aGZIVn0jWI2 BjcZUZyHjP6/hTA/NCu9/Z5+Lx+EfjyG5uGkbSroiK8ReSF5AcDuVyTjv+VVfjt8KJ/hB4+u dOIZ7GfM9lKed8RJwCf7y/dP0z0IrjKTVwPy5/4L/wDibU/Af/BaP4ja9oeoXukatZNod7ZX tnM0NxbSppFjskR1IZWBUEEHIxX0H+wP/wAFuv26f2kZbbwT4F8F+DPinqVooS41zV9Emi+x JwPMubiG5t7dAAQcuu5v9o8H6U+P3/BO34Eft7/tHW3xO8dx+OH8WRaXb22raBplzFb2PiN7 ZBGkxmwZY/3YRXCMpwi7SMMT9B/DH4S6vd+BLTwV4U8L6N8MfAlocJpGhgxxyLhQTIwVWkkb au6RyxPP8XzD+ccPwfPOMhy/h3G5PCdXCUoUpVsTFezg4RUG6ai/aVVLl5kouFNq3NNSXKfS Sxio4ipiYVmlNtpReru7630X4vyPJvC/wN8UaP8AFfR/ip8afGUnxs+MuixsmhWWnWgh8FeA JnJDSwoAPOnGExK6qSQMncqsPcfgl+wZpOu6he+JPEWoa3d6nrU7Xty/np+8kdtzNkoTySe/ Ga9V+H/7Sfwq/ZBuodM8a6ppdxeQD941mpmvoj0AeGJCuc5ySUwP4T3+jvhf8cv2f/jjDJrP hvWfDmotaDdNAqSQSOTz89swUytz1KMfTpX7Rwj4XR4awf1qnRm+ZKLqOnyQUU21CnGMY06d NNtqMVq25ScpNyfy2I4oweMxLwca8HUV/cU05X6tq7k35v5WR4d8P/2EfCvi2ZItM0C61ZVb D3c97KlvFgjO51IUkZGVUFsHO3HNfUGr3Vh+zh8NbXSNKEUurXSlYiUC+Y4Ch53XP3EG0Bc/ 3EzjkZviX9pZ9rW2gaWsMSLtS5vPlAx/dhU5IxjG5lI7rxz5rqGo3Ws6hLeX11Pe3k2N80rZ YgZwABgKoycKoAGTgcmvpzU+NPGf7Vfj5db1G0bWI4GjuJUlKWsZaRt7bmLMGbJOSTnrXlFf WfiD9i/w9rniq81C51PVjJql5JcGGIxosYZi7DJUnAGQD9K1dL/Y18CaeAJrG9vsDH7+8dc+ /wAhWkmB8eT3090iLLNLIsYCqGcsFAGABnoBX2V4G+KWpeCfgZ4M1zTtL1TU57eG3hkfT3/0 i1RV2GQActyoBXGGBIbjOdjTf2c/A+lY8rw1pr4/57KZv/Qyaw/ix8ZU/Z3utLtIvDSDw7ND IElsykSpNyREEAAXnknuGJAJBBYH1d4A+LOnfFDSl0DxRbwLd3ahVLrsivDnjHeOUHBwDnIy pyCF4/4m/CK9+Hcr3UJkvdFY/LORmS1/2ZcdvRxx2ODgt8V+EP2ytW1T4p282tm2g8OXP+jy WiIClup6SbiNzMCBnPGM4Ar7x+D/AMb3ie10fW5vtdndYhtb123sC2Akch/iBzgP1yRuzktQ B4n8Vn19fAWojwzHBJrDRlYfMfaVz1K54LgdAcDPX0Pxp8PPhFrXxN+IZ0Xybi3uUkLX8s6k Narn5mbPJbngdyR9a/ST4yfCWXwLNdarptq8mggea8VujO9j6gIMsY88jaDtGRgKAa8f1m+j mubie1SLTklRRc32xY5pkUHC5IyoGT8zcjnA53UmwE0S1sPhx4et9B0G2ic2KbMFsJG2MlpG AOXPXA5OewINZGp6rBodlqF9eagieUu/UdQYALAB0jRefm5wqc4zk5J+flvih8c9G+GtubaQ PPcBcpYQSbJpCecyt/yyQ9ef3jZzgDk/OXxF+K2sfE29R9QmjjtLcn7NZW6+XbWoPZUHf3OS fWiwE3xd+J8/xO8SCdUe20yzBhsLUnPkR+p9XYjcx5yT14FcpRRTAKKKKACiiigD61/Y48N+ FX8CRatpdsH1xcwX8s7B5on7heyow5GByOCSQa9nr5X/AGLvDHiqz8Yf2rZ2zReHblDFeSTk pHOBnaYx/Eyt3xgAsMjNfWGi6LfeJ9VWw0y0kvbxgCUXhYlOcPI3RF4PJ64IAJ4oAztXtba9 02aG8WN7aUbXD9Dk8D65xj3rF8CfsQX2teLEOu3Fzoui3OZLRGTF3dKMHbggiNgD0f5/lJ2Y BI+gtC+Hnh74JWUet+Ir2G71MHEDMmVicg/Jbx9WfGcty2Nx+VcgbvhnxfafGfw7cIkb6bfW 0glhDMskluQSY5OOM8EMucfeXLIwZvneIOHMHmkI+3j78b8r/R915fM8vH5Ng8bOEsVDm5fl 8nbp5Hzb4z/4J66rYxNLoOuWmokZPk3cRt3x2AYFgx+u0V4l48+Guu/DHVEstd02fT55F3Jv IZJB6qykq2PYnFfofomptqdo3nRiC7t3MNzDu3eVIACRnuCCGUkDKspwM1lfE34X6P8AFrwx LpWsW4lib5opVwJbZ8cOjdiPyPQgjivxjMeF6D5o01yTX3X81/l9zPCzbgHB1abngbwn0V7x f33a+/5H50UV2/xu+BOsfA/xEbW+U3Onzsfsl8iYjuV9COdrjupPHYkYJ4ivgsRh6lGo6dVW aPyPFYWrh6sqNePLJbphUtjfTabdxz28jwzRHKupwRULyLGpZmCqO5OBUf22InCsXx3RSw/S sotp3RlFS3R1nhiPTb/TL+BLe5Z5QZ10uAoE84tlpbbeQEYgsWjztYjIAJbPlf7Qf7MCa5qb 6ppl5BpviGEGGLU4EEkF8EJxb3SD76qc8ZEkZJ2sAWDdSl3KrK0cUisCCrFguPfrkflXReHL tPEGuxtdSwWM906reBiWttUXGMuuBsnUY2yqckABtwAFfT4XMPrUk60+Ssvhn/N5S/zt6n12 QcR43A4yGPwdd0cTT+Gonv8A3Zd09ndNPZ6HyDBqVzaa5Poet2D6TrtqnmSWkjb45484E0Em AJYif4gAVJAZUbirw/dqckkDv6V9D/Gf4F23jjw1Amo6dqKWyn7RbTqyw32kTfMgYMDhW6jI 3I4JUhlYg/N3iOw1T4R6rZaV4ocyx38nkafrKwhLe/fBIjk2krDOQPuEhX6oSdyJ9Tgcz9pN 4fELkqrp381/l+Z/oH4RePmE4klHKM7SoY5aLX3KvnDtLvBt33i3ql3nwH/aL8c/sueLptX8 D6pbQwagxbVNG1CJp9M1RvLKLK6KytHMmExJGysyxqj7lChSuNbcpJALA9R/hRXrn67m3AWR ZliHi8Xh05vd7Xt1dt35n7WeEPEVh8Y/D95pWvabbpqulyCDUdPmUEwSbeJE5JAIOVYHjnDH AY4viH9mKxn3Po+pXWnsekNwPtUIHoCSJMn1Lt9Kta1o9v8AFK0tPF3hG7js/EmnAxK7KMzL gFrS4UHocgjnjIYHBBp0F9b/AB38LzRwz33hrxRpTbJVjlaO4sJv7rbSpkhbnjOGHow4/Y7n 8BnmXir4WeIfBgZ7zT2ubZV3G5siZ4lH+0MB1wOSSu0D+KvNviT8J9A+MuhJDqUKSkLm2vIC BNDnujc5B9DkH06V7bpnxv8AFHw+1iXS/EdqmqPbMPMPyw3AU9HRgBHIhwdvyp3BIIIHQDQ/ BXxzEs9k7afrJUvJ5WILpTxlnjPyyDPG/DDqA1AH5g/Gf9nTXPg/dPNIjaho7N+7vokO1eeB IP4G/Q9ia+iv2WPjHbfEnwLDp7rDb6rokSQTQoAqyRgYWRQO2BggdD6AivdPiF8GtV8IW05v LaLVNJcbWuIYy6bSOfNjOSgxnJ+ZQOrDOK+IviT4K1T9mL4w2OsaAHk029lMliAS6yKcb7Zs ckc4Hcggg5BwwPrqiqei6s2p6Ba309vNp7TwLNJDcfK9vlclW9COh+lej/C/4I3Pi5k1DWFn 0/SVO5YTmOe8HXJ7xx+/DHnG0YJAOZ8E+B9U+Il+0OlwjyIn2T3soIt7c9xn+Nx/cXnpuKgg 16k+o+Hf2dNFlt4Wl1LWr1Q7xBx590QCFZv4YoxkgHA743NnOT46+Odvo9mNG8IR20Nvbr5X 22NF8mEdNsC42sR/ePyjjAbJx5cS0kskskkk00zF5JZGLvKx6szHkn3NIDW8Z+O9T+IWorc6 k6xxxnMFnE5aC2+hIG9sfxkA8nAUHFeKfHH9qLTfhmZNM0sRatr5OzylbMVs3T94R/Fn+Ec+ pFbn7SXii58H/BbW72zuJbW7CJFFJGcOpeRVJB7HBPPb618f/C/R9N8R+ObWLWdZ/sSzBM0l 2eWyvzYB6Bjg4Jzz2JwCwPvSwEy2MAuGVpxGokIGAWxyfzqWs/TPEenX2nW00Go2txDMEWOX zVPmlsbenc+laFAHoXwF+I66Bfr4e1Bg2nahJizZ+VglY8xHP8Lk8ejEjncAPIf23/2T01yy MFpGEcF59FuDgBWxlrR29MYKk84APO1yduRBIhVgcH0ODXsPgHXrT42+Bbnw9rjM2pWiD96M CSRRjZcocY3qcBu2eo2uAUwPyJvbKfSb+W3uIpLe5tnKSRuCrxsDggjsQa+5PA37Y2h+Fvgd p2q3d99ujtoktoorvbPexzooyvbc3Q7jgYIPGcV5v+3H+zNeaLqt9rsFuqajpyj+1Io1IW5i x8t0ntgc+ynOCjV8vA4IJAIHb1oA9F+PX7RPiL486nLdXrTW2kLN+7tkJMYbHBdujPgHHYDO AOa3P2MvFut6N8Rjp9hZ3F/peoAC+RB8tsB92Yk8DHQ+oJABOK9u8C+DvC3xh/Z/sbC30o6b pN5HkRIMSW8ykqZFdh8zAg/Oc7h16kV6j8Mfg1ofwp8KQr9lXT9OHzJCvNxftj7zHrz6n8MD FNAXtA8MTa1uldltrKLmS4k4RfYep9qh8d/FHSfh94ZuXS4TStJiH7+6mOJbg+nrz2VeT+lc b+0F+0/pnw30xUumjafbmz0m2YA+zN6D/abk84B6V8//AA70e+/bC8a3V74j1lINP0pgy6Xb sVYKemwHgL2L8t244wAZHx6/aq1L4kiXTtHE+maCxKFslZrwd9xHRcH7g/EnoPLPD1tZXmu2 cOo3MtnYSzKs88cfmNEhPLAd8D/J6V9ofFL9n/R/HHwzGg2Npa6c9gpfTnRMCCT0PchujdSe vJAr4s1vRbrw5q9zYXsL293aSGKWNhgqwOCKAPtrSdC8J/AzwLbXdo9pYaTAyzS3btue6DKV DFhy5O7IA+gHSuW139tHwtZ+DX1CxFzdahJI8UNi6hJMr0dzkhUPBzyTnGMg4+VNT8V6lrWl WNjd31zcWemoUtoXclIQSTwPx6+mB0AFezfsvfs06Z8QtNi8RaxeRXlnHKyJp8LHJZT0mPUe u0dQQc4OCkgPav2cvGus/EP4ax6xrUtrJPeXMphEEZQRxA4CkeoYN68Y5JzXrPhG/iu45dIv GVbW9OY3Iz5Ev8Lfj0P/AOuuciit9JsFSNIbW1tkwFUBI4kA/IAD8qlilWRFdGDKwDKynII7 EGmBxf7SXwSPxP8AB9zprosWs6axls3Y4AkA5Qn+644+u09q+HLq2lsrmSGaN4poWKOjDDIw OCCOxBr9PNUA8YeHBqCgHUNPAjulA5kjx8smPboa+QP20fgqdL1AeLtOhAtbohNRVRjy5ScL L9G4B9wP71AHguj6lPoOtWuoWj+Vd2cglifAOCPUHgg9CDwQa9y/an/bI0/4UfsRat430x10 y/kQ2jvERvsHEbySuvfKxxyFenJU+mfB8HAODg96i/a40Pwd4h/ZxvfAlncX2v3+t7bnUJGU ww2oMMkbQqh53lJWUn2HtX0fCeW1MZmdKEYcyTu77abc19LXte+60PleNM1p4DKK1SdTkbVl b4nffltre17W2epy/wCzp/wTj+Bd9+xl4b+Pn7Zutax4gf4nRW+raT4Yj1m/tdJ0S1u1aazQ JZFJp7p4SJHdicdNoCMxoftVfsy2/wDwSh+J3wi+LXwU8V67f/Bn4lammjQ6dqupvfvoN/Jb vParbTtl5bO5ihkUxux2n5tx3YFT9ln/AIKAfB3Qv2UvDvwP/a/0rVdL034fRW9jpniKPSL/ AFDS9btrZTFZuj2SvNb3Kwjy3RgMgZ3EOVEf7fX7aejf8FHvFXwu8A/Cnwpq+ifA/wCFF+ur 2t7qlg9hJ4h1CO3a3tBa2z4kjtYI5XbzJFBdm2hV2ZPt4SnXhmNNSc3iOa9XmvZQ+2p3+za/ NfS3yPAxtXDzyuo4qCw3LaioWu5/YcLfavbltrf5n6jfDPx9bfEnwXpms2o2w6lbR3KrnJUO oYD9a2ru9FuVRVMs7/djBAJ9z6Aev4ckgHxz9jqz1PSvhfp1m8NukVtbpCjNKxKqqgA4288D pkfWvSB4ik0r4gW2jHS7+aO/tHuW1QLui3o2PLbH3eDkZwOQADk4+FruDqS9j8N3a/bp+B+h 4ZVPZR9t8Vle3e2v4m5bW7IS8rCSU8ZAwFHoPb9T+WGatq9roOmzXl7cQ2tpbLvlllYKiD1J NWK+U/239SuG8eW1uuure2bRBjpqSD/QJAADuUd2ByC3zdegxnJKxse/+Cfjj4Z8fabql5Y6 jGlro8m25kuP3KqvaT5uiHBwTjoeBXhP7Tv7TumeP9Im8O6NZxXtoJQz386fxL3hHUdxuPYk Ywc1wHwf+BHiH4uXW2xjks9Kc7Z76UEQgA5wB/GwPYdDjJHWu8+IX7Fd7o2t6emj30T6VLEP tl5eusYtXBALEDqGyNoGTng+tMDK/ZY+AukfFqe6vtVvxJFpsiq2nxErJICMhnbsh5Hy8nB5 Hf6mvtQsPDOnRWEcAkEcIjhs4lBPlgbQMHhVwMZbA7e1ea/DD4Y6Z8KNJkbSi9tNNHtutWug BPMuQcIjfLEmf7wzxyM4NZfxL+POlfDWCW3t2ae/fkx7t08hwPmctnbx3fLdMKw5qXLogPrr 9mL4s3urvNoOuXSzSsN9hvJd1QD5oWc8uQOQSM/eHQADzz44/DC+8K/EprCC3ZrbWZjdaO9t CWAcHeYNg/iQjIA4ZMHqGx8r/AX9pjUP+FjE30q2pu5Fe3eEkGJ1ORyxJJHUEnOAVAPygfXH 7QHjD4hftCeBX+GHhXwVLHf+JtCWbVfG+rPLZ6B4ciuFdUltmidLi7vgo3rFbmNY2Kl7iI7Q z8gPmHxx+yVcfEX4oTahbTw6TZ3bs+qRkbntLgEbgi8ZD53AnGMnOD8tcp+1P8CtC+E+naPN o90kcsi+TPayzBp5upE4BPTPynAAHy+9fTXiHRfEXhTwjot74m1rRtR8VXNnNaazf6KyvDqI ileOLU0TBWOSaMLM0I3KjvKgLgKx+IfivoWseG/H2o2muXE15qCSZNzI5f7Sh5WQE9VIwR6d O1CYHOUUUUwCiitzwF8ONZ+JesrY6NZS3UpI3vjEcI/vOx4Ufqe2TxQBS8NeF9R8Y6xFp+l2 c99eTn5YolyfcnsAO5PAr6W+Cv7GVloD2194nQatqMjARadEhliVj0UgZMrewGPY16z+yj+y 7qPhzwsdOsBaXE0krNe6qYPLhQ/888/elK84A6c52ZFfQsFj4V/Z7tFmnd7/AFy4j4Y4e7mG edi9Io89+AcDJZsZLgcx4K/Zu1PUUjbVnTRLSMBRbwlJLjA4xkZjQdMY38dhV74jfHbwd+zd 4VuLfSv7PjaIsZZGlJghkxjMsmS0snGAilnOADtGDXK+NfizrfjppI55xZWDZAtLZiqsvpI3 WQ4OCOFIx8uea+Y/21vhRc694dtvEVi8zro8fl3NtvJRYieJFXoCpPzY6jB/hoA5v4//ALdO tfEXVLkaNNcwebmNtRl4nKZ+5CvSFOnT5u5IbJPpH7Af7TF0wTSby4abVtJGYTLIAby3JAKs x544BPQDy2IYx4r43rU8F+ML7wF4ostX06TyruykDrn7rjoVPqpGQR6GpnHmVhM/Y3WbqJ7e 38S2BL2rxBb5cbWMIz85U8h4juyvB2lwQWCgaasGAIIIPII714v+x/8AHi08beH7KSGUDTtV VdqMwzaT8JsPYZICHplthAYyOw9VsLI+FNUOlkEWMoMmnseiL/FB/wAA6r0+Q4APlsa+N4ky 3mj9bprVaS/R/wBdPRnRQqfZYnjPwXpnxA8PXGlavaR3llcjDIw5U9mU9VYdiORXxN+0P+zb qfwO1fzkMl/oF05FteBeYz/zzlxwr+h6MBkYOVH3bVbWdGtPEWlXFjf20N3Z3SGOWGVQySKe xBr85zLK6WMhyz0ktn1X+a8jxeIeG6GaUve92otpfo+6/Lp5/mPbQpc3Es7orNv2ISmGULx/ 6FuOfcVZr1r4/wD7Ll58KxdaxpKS3nh1ruVWxlpNPJkbar9ymCAH/A84LeS1+cY3B1cNVdKq tfwa7o/Dczy+vgsRLD4iNmvua6Nd0/61CiiiuQ4DUt9X+3PA005tNQto/It7/Z5o8onmCdMj zYTk8HlckqQcEO+IvwmsPFGhajaTWUOqaXJGgvbSaBpISrqGyjMMSxg/xDlSOeQSMmtKw1tm s4rK5ubyG3ilE8E9tJtmspBkb0zwRhmBRgVYEgjk17uEzGFaMcPjJNKPwz6x/Vr8j18Lj1Pl p4iTXL8MlvHqvO35bnzD4++GuufBnUnljS98Q+EJABBNFE9xqOltnAilVctPGcgLIo3jo4bm QlfWl14ObV7exMM1g+q3iSOI7ZXSC6RGAMibhiNiCCYix25OCcUV7/8AamYYdKlOl7S20le0 l0e2p/TPD30nOLMowMMBjMPDFOGiqScuaUel2tJNfzbvrd3bt/szf8FEfEHib4t3Vz4f8K6J e+D7HX7vw7rL2vigTavp627Tqt1fae1ui28Ehh3RyC4dts8TbSjtj3GT9uH4QfGjwrffEjwH 42Fre+G9NsdTee70i9sk1mzvXMVqsSzQobwTSr5Mf2fzN0wEQIk27fyb0zwf428O6U93c+Ir HWtf0Dw7qmi+HdQtNJFlqc017ZvaRm+uWmYS28bSCdo1VQZY1kABXY32p4N/Y+8T6Bd6B4jh 8eaLe654WGhRaEkPh3Zows9Md5IxLbC63Syy+aWLpPGqmK32qvlkt/R6Wh4Z9N+K/wBtr4Qf Fj4e6RcaprWpaJ4mvNSn0ey0waDqE+tQ6hCu+e2NgkBuiAi7mVolIQbjsK5X5XT/AIKgeBob /wAP3Op6f4k0bR9R0vXdefUZtJ1FbjT7TTL+G0jvRbpb+f8AZp1lkmFxhEhSBxIVYMF988B/ 8E/tVPxMtvjRonxGs9Z+IMtprc1zcLoptba61DUnsFZhE87+Slva6db2scT7n2ht8pZty8j8 NP8AgmJbfFD9njVfB2r+MobPxLa/DXQvhXKsehvEdItbF7w3Umx7l2lF/Fd7XLPjMMb/ADMu FAPSfCH/AAUn8M+EfidZ+Btb1efWdRubldPjmj0+42x3TQfaEtHvBH9kNwYcOsLypMU+bD5y ec+EPx90f9uXWn1Dwf4Ri082Hh238Ws6XKzR3cN3qOqWlptTy12XMkGnyT5zkCcRsD8sg8Y1 /wD4JieO/Gf7RaXl34zDa5pWt6pr2mmfTbq4nthdWl9bWoed7zyRaWjXYaIQwxbxborL5u5q +of2Rv2UfD3/AATZ8I+IEm19vEFxr0ek2djDDYi2mgs9N0q1sYrVFMrB1EsdzPvJQL9r2nJX e4B6D4F+EFj4I09fEPi6WCKS0xMlu8gMNocjaWxxJLnoBlQSNoYgNXM/E/4x3nxBaWytRJY6 GflMZ+Wa8HcyeiH+4Oo+912jG8beOtS+Impi51FlSGJy1taISYrYdj/tPjgufU4Cg4rxj47/ ALTel/CW3ksrMw6nr7D5bcNmO3/2pSOn+6OT7A5pgbep/HDTPC3gaTXNbtL/AEOISyQ29pdR hLq62nAKx5zz74wOTxzXldj+35Abl1ufDMqw7zteK8BbbnjKlAM4968P1zWvEnxm8Std3Avt Zv5WEarFEXEeT8qKqjCjrx9a+oPgp+y7oPhLwfA+t6Ra6jrN5ErXQu1SdYG67EGMDHcjJJzz jAoA8x/aF/ag0b4t/DVNK0y21O1umvI5ZluI0CGNVfOCrHPzbeoFeR6v8P8AWNC8K6drd3Yy w6ZqrMttMcESEew5GecZxnBIyBXv/wC07+y/YQ+GG1zwvp6Wk+ngtd2kAO2aLqXUdmXqQOoz 3AzF4U+N3g7xX+zW+j+JiLZ9Mt47BraLBnnKr+6liB7/AC5JPAYHPBGQDwn4YaLF4j+I+hWE 8jxQXd/DHI6vsZVLjOG7HHQ+uK+/kUIoUZIUY5JJr4M+Eugazq/jvS5dFsWu5be9hHmSWzS2 8JZwAZcA7U65PoDjpX6B+F/COr+MpHj03T5Lx4NondXRIoSRxlnIz64GTjBxyKAKFbPw60/W dU8Y2zeH1zf2TCR5X4ggQ9RKcH5WHG0fMeoxjcvZeHP2ZL66ZH1rU4LaPPzwWAMjsO2JXAA9 xsPHQg8jm/jZ+214C/Zsurbwjo09o2pMxSVoUM1tppIyZJip3O5PUAkkkliMGgD0749fDYeO PCcl1aW4n1fTkLQL1+0RkgyQkfxFlB256Pt5wWB+JvC/7F3h+f4iTarl7/SrhhNY6YqnYpIy Qx6sg7L6dSe/v37Pn7RcGsa5qmpWmsSeJNLZFm1aXzCzWfXE2DgLhQQUABKqNo+QKe8+Mnhd /Ai3OvaJCkVtqjH+0WQZMDMc+cv91XOd+ONxVsAl2KA4u20+w+HkESyxQXWoxKAlsuBDZgD5 c44JHp0FfOH7RX7aq6bfXNjoE8eqasfklvn+eC2Pog6Ow/75HvyK4/8AbB+NHiW38S3PhhYp NJ0soHMiMfM1FGH3iw6JnI2juDknoPLPhT8Gtb+L+sG20yDbbxEfaLuQEQwD3PdvRRyfpzTA yLa11j4keKdkaXmr6tqMmT1kklY9yfQep4AHYCvpn4MfA3TP2dNJk8U+J9Tjh1BYSjYlKwWw bqgx/rHPTuM9AeDVmS48Hfsb+DzGmL/XruPOOPtN4fU9fLiB/Dj+Juvzl8VPjBrXxd1s3eqX BEEZP2e0jJENuP8AZHcnux5P0wAgPtvwL45034jeGbfVtKnM9pcZAyNrxsDgqw7EH+h5BBry f9rz4Df8Jlo7eJdKgB1XT4ybuNR813Co6+7oB9SOOwFbf7J+oeGo/hAk2jgWbQEtqnnygukw X5nY8AKQMg4Ax7g16jb3Ed3bxzQyJLFKodHQhldSMggjqCO9MD85q6n4afGPXvhM98dGuUiW /i8uRJF3oD2kA6b15wTkc8g13v7WfwFPw+1069pcIGi6lJ+8jQYFnMcnbjsjckehyPTPPfBv 9nu++JYk1G/uE0Xw9aL5s97PhS6ZOdgPB6H5j8owepGKLgb+rfFPxx+1Ld2ugabbG2s1jQXi W7FInPeSZ8cJkEhensxAr6r8NaOnh7w7p+nxqFjsbaO3Ubi+AihQMnk9Op61xngzxT4D+GXw pTUdIvbO30CNivnLky3Eo4III3tIcdMdMYwuK7Hwt4nsvGfh2z1XTphPZX0YkiccHHcEdiDk EdiCKAN7w5rknh7VY7lBvUZWRO0iHqtQfFTwppn9mXkd2IZvD+pW7yFpDhBCQdwJ7FfXtgGq 9Ta94bi+LHwx17wVd3At11q0lhs5z0t5mQgfgSea0oxjKpGM3ZNq77LqzKvKcacpU1eSTsu7 6L5nwp+0P+0bouq2MHhfwLpdrYaLpshZL4Q4nmcjaWjJ+YAjjcTuOM8cVjfDH4S6F4WuLHV/ iBLOkEzJJDo8AzcyoT/rJh/yzTHzbThmHTg1n/AuCz+Gf7Rljp3izToytpevp9yk4INnNkos g91fByenUYIBHRfHH4ZXvwr+IN5YXTy3EM7G4trlySbiNicMT3YHIPuD6iv1fibMP7Aw8Mty qHIpq7qbuXTR9/PomrJH4vwjln+smKqZrnM+eVOXKqeyj1V128urT5mz3H4xfsT+Cvi3bw39 rpNhG8kK+VPajyg6Y+U5QjcMYwTniuS+G/8AwT/03wnrKTGFQiHPIyT+Jr1n9kuw8R6X8K4L fXoBDbqQ+nB2/feSwzhh2GeVzzg9BgV6fX5pVzbHVKKw1StN019lybj917H63RybL6Vd4qlQ hGo/tKMVL/wJK/4nMy32i/B3wl9o1C7t9PsrdcbnOC5x91QOWbjoASaq/CH426R8ZrG9m00T QyWM3lvDNgSbD9x8AkYbB78EGvnX9tRreT4oxvBrR1EmHbLZ+aXGnOMAqOyhuDjrkHPar37H nw58VJ4zt/EFpH9i0UqYriSfIW8jPVUXqxyAQ3QEdT0rzz0j2/48ad421nRoLTwfPbWonWT7 XMX8udAFBQRt2LHIyBkHHIGTXxYulX+pa41mLe6uNSklMbQhGeZpMnII6ls5zX6CarrtrowQ TyASyf6uJRukk+gHbJHPQZ5IrhH8M6dFr95qg0630641Zv3ywKXubs45VmGTggZKJweSS3Wk 5JAU/wBn3xdqtv8ACTTrK/tN+o2LPaAFWiEMaMVXzCVALDBGE3ZAUkgk40fEfim10eCbUNUv YXNocPNKfLtrVsHgDnDEHG1d0hB7jpwPxl+PUHw+ntrK1ls7m5jZludOhJLRJtIUPMjYQ7sZ RATgH5hmvFL7VvFX7QHiqG2SOfUJxxBa26bbe0TOOFHyoo4yx5Pck1Nm9wOx+Iv7SWpeLtQG neGo7lnkfbHciL9+5xj9zGM+Xn1JZ+eqg7Rzdp+zL4+1e3N0vh68xJ8x86aOKQ+5V2DZ/Cvq T4HfA3TPg94chRIYZ9YmQG7vCuXZj1VSeQgPAAxnGTzXdVSQH58eIPCus+AdVji1KxvtKu0O +Myo0bEg/eU98HuDX1Z8Hdel/a4/Z7vvBct3o2pa5ZXemTRaB4ivZbbR/ENtb3Ikl02eREla OCYBQQsUi8KGjmUPG3pPivwhpvjjRZdP1WzgvbWUEFZFBKnGNynqrDsRyK+T7qy1L9kT47Ws iT3L2KSJcW9xGAHki3fK4zx5kbDoeCRgjaxBYHuHwEiuLh9S0+PwFNonh/xJ4gv7rT9V0GzS w8Jabfm2gRdKsYZ1hu7mGU2U8hvvs8MMt5dOI1YTDbz/AO0Z8FpPG/giaS2tTH4h8JFoTD5Z SWa2HIjI65QZAzzuRx1Nan7VXwx1D9q+bwz4i1e+vvGHhZGtobzR9HtprvWbW7m0vVtPSXSr cxNax/ahqEc/2ueSBLOWwDvJIi7Yus8C/E7U/GWteN7jxP4e07w54m0nxd/Yt7p1neC9OlxS WkV1CLi6WZormaT7QhxHHD5JZ0KuNssitrcD4VpUVpGCqCzMcAAZJr6J+Kn7E3iDxR8THn8J 2tkdJ1WdAzXF5DbR2k8rEeUPMYFyxyVRAWPIC8V2nhjRdO/ZV+H2tz2Wj2Gp+JfAPiW3t/EN xrujRtayQXOlQXsc/nCOa4trWMtLCBFE8010nlqv7xcMDz/9nf8AY4uPEUVz4o8a2WpW/hbQ rZtRu7G3KRXl3CmGYF5XSOFNu5iXdW2owX5itd9fftH+HfCHhjwx4f8AC1xN8A2161W81zX7 3RHvT4VguLGV7K8tnvokWS0muYpIjd3EQKsI4pI4ZJ4yPNPiB+0XqXjLwPqHxHuNAu9F13Sd TtdI0TR9S8Zx2Wj+FNctI5YtX0G+0+aeOS+F7bmV42gtbm6nivQmy3kgix9JeF/hjpXwt0+1 tWm8a6nJN4Yh8N2sXiXUYprjw3pcypK+kI9vHE+QRFG080ks7G3QGbcASmwOw+CX7bdx8R/2 X4PFuuR6Z4KuLCyl07WBcLLa3drrMbJ8sVnNF8ttLE6XEZkcyBLiJXjDBgPmTxZ+3bHN4+tj YWkt3pJuAb+9uizXN4vQsoPIx1G7k4Awo4r3HV/BGhaj8OB4Rt9F0/S/DqpKPsdojANJK2+W d3cs8k7yfO0sjM7P8xJJJr5A/aF/Z7n+CV1YSw3Et/pl6mwXDIFKTAfMpA6Ajke2R2yWB9de CvH+kfETTJbzRr2O+t4JmgdlBG117YIBwQQQe4IrVuraO9tpIZo0lhmUo6MMq6kYII7givjr 9kfx7qnhP4owWVnbXV9Y6tiG7ghUt5YzxNjtsJ5J/hLd8V9kUAfEH7RHwfl+EHj2W3iRjpN+ TPYSE5+TPKH3QnH02nvXBV92fHL4UW/xf8BXOmuES9izNZSnjy5QDgE/3W6H2OeoFfDWp6bc aNqNxZ3cLwXVrI0UsbjDRspwQfcEUAetfsffG9vhl44XS7yUDSNYcId5IWGYjaGOCMKwOxsY 4I54r9MvBPiKL4qeDmtZLgxapYbHWbhpEYZ8ubAxk5DKwwobDjGxhn8bK+3v2E/2m59V0u3t 7qd5tX0MCOdC6g3lucDdlu5AAY5HzLGzHHFZVKae6v0fmv6/UTdtT7L0XUn1OzLTRG3uoWMV xCTkxSDqM8ZB4IOBuUqehq3WZrVzBGbbxNZSiXTrmFVvNuQpiPKT4PQpk7s4+Qkn7gFadfmG b5c8JXcF8L1T8v8AgHdTnzIzbC1ivDq1tNFHNBJOUeN1DI6tEhIIPBB3HIPWvlr9qD9kJ/BU dz4i8LxSTaQpMl3ZDLPZDqXTu0Y7jqvXkZK/VUC/YNXmVgSl83mq3YOEClf++VBH0b0q7Xz+ OwNLFU/Z1V6PqvQ8rO8jw2Z0fZVlZraXVP8Ay7rr66n5j0V9PftO/sc+YbnxD4OtQDzJdaXE vXuXhA/9AH/Aey18xEEEgggivzbMMuq4SpyVFo9n0f8AXY/B83yfE5dXdHEL0fRruv8ALdCU UUVwHlmt4Y8YXfhd5BCxeCX78RZlBPY5BBB+lFZNFdtDMsTRjyU5tI6aWNr048sJNI8CTpXt 37L37SzeBJ4fD+uzM2izNtt52P8Ax4sT0P8A0zJP/AevTNcX8cvgbf8AwV8R+TIXutLuiWs7 vGN4/uN6OO/r1HoNL9n79ne9+MGppdXIntNBgkCSTIpMly+QBFEOrMSQMgHGehOAf6/P6LPu LwV44vfAOqHUtMmiMcwBuIXb9xdoBxuI6EDo4yR/tDKn3C08Paf8R5ND8W2i32kaksassuwR yzQE5aCVTw8Z5we2QynnJ4n4R/s+6b8OPDtnf6+tvbWulwoLawdt0NmBgKZCc+ZIOMDkBum4 4Yd1Ndaj4uYyGW60fThzDHH8l1P3DuSP3YzyI+p/j4LR1w47MKOEhz1n6Lq/QqMHJ6HS6l9p /s64+x+R9s8tvI87Pl78HbuxztzjOOcV8yeLU1iHxRcjxClwmsSDLmUgrIgPBiI+UxjPAXGM nIDE19B6R4mmt7tNP1TbHcSnbb3SDEV17f7En+yeG6qT8wWbxj4P07xzprWGpW5dD80MqnEk LYxuRv4WH5EZByMit8PiKdeCqUndMTTTsz4h8bXer/DHx1qHi691eWfwglgEnsNjPJFLkBBE qjAyxGWY/wARB4wR8pfFf4gD4r+OL3WBY2+nPckBYoskuAMAsf4nxjnAzj6V+hXxX+Fl14Ft rmHV4UvdCuEKNe7MwFGyCsw/5ZnHUn5TkYbJKj4J+P3wek+EXi/Fqzz6Lf5lsLgNuBAPKFh/ Ep/MYNbCPoL9kb4heH9a+HVvpdlBZaXqdkdlzbqQrXT4/wBcMnc+4DnOSCCOgFVP2rvj3rHw vjt9K0mzktptShLjUnAKoM4Kxj++O5PTIwDkEfLOm6rc6PqNvqVjM1rd2kiyK8Z2tG4OQwHp +nbgEV7jq3xgvP2r9Fs/B9r4ftYdVkKzyX01yTFa7B88iqFyM5Ixzw2OeoEBZ+Dv7X82neBR pWpWl7rXiGF1g08KSWvtxwodjkhlPGeSQR3ya88+MfwQ134eJa67q1jZw2urTM8tvZMRHZOx LeTznHy5xjIGCOwzg/FnwIfhV8QLrSIri6m+xbGS4kgMBkJUEsoz93dkAjriveP2Rri1+KPw e17w1rCtexQ3JMgdssI5hlSCeQwdXYH1waaA734J+NPBEfgXToPD91penRSoGaze4RblJOjC QE7mbPGT14xxivVvCvxK1bwBY3n9mXlpBaXn76XzohIsbBQPNU5GDtVQd2Vwo4718A6N8HZ/ EfxoufB1neRiSC7uLYXMinbiIOSxA9dmPxrvJ/2J/Hdkr22nahpt5HcfJ5MN1JGZQexUqByf c0Add+0v+3VqXiSOfR9E1m+1PzAUuL6R9sHpiKJQIyf9sr9PWud/Z2/Yx1L4rxR+J/GFxd6L 4YmbzFdwTe6qTz+6DdFPd2/AHOR6b8Cf2KNK+Ehi1fxylrrXiFcPb6QjCS0sj2aY9JHH937o /wBrqND9oj9rGx+H00sJkXVfEDDCWiHEVqMcbyOFGP4RyeOmc0AdX40+I3hf4E+AIrK3htfD 3h61yLeytxma7cDqf4pJDxkk/U967X9i/wDam0r4t+FU0i5UCzmdrSKC42ubUnIFvJ2KOv3C Rjkp/dFfnJ4q8X658WvFa3N/NPqWo3biKGNV4GThURRwBk9B+p5r6V/Zg/Zw1D4YmTV9XvZY r2+g8ttPhb93GpwR5h7uD02/d55OeAD179qn9k/StX1KxtNQS4OmCcy6ddxt+9jXrJasxz2G QTyVAPJVjXiHxf8A2j9J+CmnP4V8GWdul7Z5idwn7iyboeD/AKyTPXPGepJyK+2fh54ltfjR 4Lu/DeuOW1K2iB80YEkyA4S4TIxvVsBsZG7BIAcLXzz8Sv2YfD8/xD1N/EGkxT6s1uLeSQZW OZCCFuEH94qMBskrtx1U0AfCms6zd+IdUnvr64mu7u5bfLLKxZ3Puaq10vxb+Hcvws8e32jS Tx3KW7BopVYEvGwypYD7rY6g9/YgnqfgX+zLqvxcljvrkvpughvmuWH7y4A6iIHr6bjwPcjF CYHL/DLwR4i+IupzaPoIuSl0F+14kaO3CA5BlI4wDnAOTnoCa+z/AIP/AA+m+F/gGy0abUZt Se1yfMcBQmTnYo67Qc4ySefTADvA+leGvh86eGNGaxtbqGH7Q9qrg3DrkDzX7kkkcn27V0Vw SLeQq6xkKcOwyF46n2FAHL/GHxr4b8HeDrhvExt5rK4XaLR1Ej3ZByFVO/IHPQdSRXyT8Yvj 1qnxYvDEqLpejRqqQ2EDYTamdu/GAxGTjgAdh3rF+KXiLU/EnjnUJtV1NNXuYpmiFxE4aFlU kDy8cBO4A9a56kFy9oItbvVbO21K7uLXTGnHnPEnmGJTgMwXIycD68d+lfcPwRsvDdj8OrJf Ckgm0h8sshJMjv0YvnBDZHIwPYYxXwhXoHwx+O+t/DzwXfeH9CtkF7q90HjuVDPMhKhNiJ0L EhcHryeCcEMD7cpUdo3DKSrKcgg4INee/Bi/13wX8JI7jx5eW9tJa5YTXE2ZUh42iVicF85H HOMA85rv4J0uYUlidJI5FDKynKsCMggjqDQB8jf8FJPhgLHx1YeNrOLYmvKIdQ24AF3GPv8A H99AD06q1WPE3xh8MfGP9mLSW1i+VfF2mfuIkjXfMZEABLAfdjdcHJ79M4xX0D8f/huvxW+E +raOED3Dx+dbZ7TJyv58j/gRr8//AAbpkv8AwkkmnBXW4nDLGhBBZ1ydmP7x5A98DvX6bT/4 WuG3Derhtu7j/wAN+MUfkdVf2BxWqm1DF6Psp3/+S19JM+rP2Vv2jtP03wRc6P4k1CKzGiRe ZbTzN/rIMgeWO5ZSQABkkEAD5a5j42ftjah4u83TvDJn0rTWyr3J+W5uB7Ef6tfp83uORWN8 Ff2VNa+JzQ31+JNI0RiG82RcTXK/9M1I6H+8eOcjd0r0j4p/seaZdnQX0C3vdLtCpW4nmik8 q8i+8JEkYYdjkjKZXBHTAB/MW7H64eb/ALKWg+FfE/ji6XxMhmuIIvtNqsz4tnKnL7/UjggE 4I3ZHTP1DfeKZZ7cpYKLC0jUg3EyBSABwUQ9B7sO33SOa434c/CjSvAsBtdFshe3seBNcSHC q4HVm5APPQZYBuBiuf8Ai3+0Tonw5lks7Qw+JNfgbgYxZWT+pAJ3MOO5IOeV5FTdvYDs9c8Q WfhTRZdUv7yPT7Ij5r+8y8twecCNPvSH0xhQCCMgYrwrx5+0PrHxB1RtF8HWt9bxXn7kyqN+ oXwxyCV4jU9dqYHvjIri/Htz4v8AiJpzeLNbjv7nT2lEEdy6FYIyckLGvQLxjIGM9Tk8/SX7 H+n+GJfhtDfaNZpFqg/cajJIQ8/mDqN3ZDwQBgfUgmqUUgPmz4mfBLX/AIS2Wmz6xBFGmpoS vlv5nkuOsbkcBsYPBIPYnBx6/wDsQfE7T7WG78M3MVra3jlrm3uAqo1yoHzIzdyo5Ge2fSvS v2m9V8LR/DS8sfEt0sJulLWiRjfceao+V0X2PUkgYJBIzXxUqvtZ1DbV4JA4Gf8AGmB9ZfGH 9sfSPBTy2OgJDrepJw0u7NrCc9CRy59lOPftXJWf7fF89mkb+F7ea8PBeO8ZUY+ybCf/AB41 f/ZR+APhfX/C1t4lvJE1u7Zyn2aWMCGzkU8qy872wQcnjBHHetL47/tN2vwm1C68P+HNLji1 aFQss7wCOG33AEbVwN5wQc/d6fe6UAedaj+2j4u1LxNFPE9hpdkoMRt1t/NVQeC7ZO5mXqAC Bx0659c8S/sz6X8SvAbSvrFzquuX4juItbuGL7h1CqgIVYirH5V9QSTgV8mS63Nea+2o3Sx3 c8s/2iYSKNkzFtx3AYGCc5x6193fCjxlpnjvwDp2oaRHDb2jxBPs8ahVtXAG6LAwBtPHTpg9 DQBN+zt4RuvgnoN7od3rF7qejXscln+5llsrq3tpVAkEc0LrJG4bcyOjK6E8N0x474f8U+Lv 2TvitBpOrWln4O+EnhjWbo6hqPkNpnhubTrm5nMFjaQIZZNcv7y2MEgdY/tsV3DIWlliuVRv fqual4XT4k6LGY78aP4v8PQzLoWuWmi22o65YWsqg3ltp8lwCkE0yRRorMGUEfdPGADofCfw e+H/AMXvgEdV8XaloPi3wZ4pskl2K/8AxLpEJDRyKxxJ56OAyOux45FBUK6Bq8Tn8O+FvgvZ fEm+8c+OZfiF4P8AGOi6ToOlaP4m06U6uIrG6vpl8+4Rw104F2ojnIjnAgiMjM6GV8P9mHx1 o2j3+qfD6GTUbe0bxBI2j2k97ceIrfwteyxlrjTb/XWLwvq17dNNO9sksqxSlkMu6SMPk/tm /Bt/Ffh5PE2nxvJfaRHsuY1GfMt8klvqhOf90n0FAH0H4G+JjaD4O0e08ICx0Xw7a2u2xttP j/cFHO8yHfuLuxJYuxLFmZidzMTxPir4x+HtJ8Y22i6nqsL6tq0mwxu3mHc2TmQ9tx4+bklh 9a+X/B3xF+Inh74F3celQXEGgWcuf7R2ESwq5wUjJP3dxJLAEqW6ivLDNPd3bSl5Zbh2MhfJ Z2bqWz1z3zQB+hkdwbC4WCZiY5DiGQ88/wBwn19Cev1GTS8feBrD4keE7vR9SRmtrtcbkwHi YHIdSQcMDz/9avMPgR+0rZfEU2HhjWFP9sNbFXuNwMV1Ih6A/wB8qN2RxkHB6V69ZyvFIbeV md0G5HPWRfX6jgH8D3wJWg2ZXw++GWi/DDRxZaNZR2yEDzJSN005Hd26k9fYZ4Araa7iS6SB pY1nkUusZYB2UYyQOpAyOfcV5L+0j+0vL8ILlNJ07T3m1W5hEy3E64t4lJIBAHLtkHjgD36V 816X8ZfEFh8RbfxRNfzXmqQPuLSnKyIRgx4HAUgkYAGO2KoR95V85/tp/BQyL/wmOnRAlQse pIo5I4VJffsp/wCAn1Ne7+B/GVl8QPCtlrGnyb7W9jDgH70Z6Mjf7SnIPuK0L+xh1SxntbiJ Jre5jaKWNhlXVhgg+xBxQB+dFbvw18fXnwy8aWOs2RJktX+ePOFmjPDIfYj8jg9q2vj58JJv hB4+uLJVdtNuSZrGU874yfuk92XofwPeuMtrWW9uI4YY5JppWCoiKWZyegAHJNAH6pfspfGi w8W6JbWizrc6VrKGWzZwNqOfvwsO2Tngj7+7JJcV6VpSN4e1STRpeIo1Mtg5bJkgBAKeuYyQ vfKlCSSTj4b/AGR/A3if4YeFbp9dkSxs5ZVubO2dj59pID9/I+5nCkAHIIB4PX7d1e7utR+F tjq2o2/2PWrSKO6hjIKt9oI2rEVPQy7thTqPMwDkA15Ob5fHFYZw6rVPt/wH/WxVKTi7GrqF oby2KKwSRSGjbGdjDkH/AD1GRSade/b7VZCuxwSrpnOxgcEZ74Pfv1qeqMqnTtUEyj9zeEJL 6K4GFb8RhT77Pevy070Xq8F/ae/ZFi8fNc+IfDUUdvrjZkubUYWO/Pdh2WQ/kx5ODkn3qiuf FYWniKbpVVdP+rrzPNzPK8Pj6DoYmN107p90+/8ATPzMvLObTruW3uIpIJ4HMckcilXjYHBU g8gg9jUVfbP7Sn7K9j8YbeTVtMEdj4liT7/SO+AHCSejDoH644OQBt+Mte0G98L6zc6fqFtL aXto5jlikGGQj/PXoRX5zmuU1MHPXWL2f6Pz/M/Cs+4fxGV1uWprB/DLo/8AJ+X3XKdFFFeS eCeiWOlyfEjWvhneaj8QdH8f658YLpba68AeHroXfhzRfDxhdpLu3DKJ0nspNjtqUoR5pZDA Y4xLDFF9Z/Bz4MaZ8HPDsGqanbwWstmgjs7SJNy2Kn5VVVXO6Z844ycttXOWLeKft7/sw+Kd SsLnxD8LvD/hKWPU7a4j8T6B9g06zh8VX0txa/ZLzVJZrd/tNlbhbgzx74pRFLJJG5ljiUs/ Yq/aSibRPAPg/WI/FPiOCbTZbXwt4xnXOneL5LZWkvJbGKSSS8MEUTokNzdZa5hhd0d94e4/ r54znwv1jDrn0ul/Xb7z+luXWzPpyHT59e1CLUtUjCywktaWm4MlkCMbjjhpSOrchQSq8Fmf Toor8txeKq4io6lZ3b/qyO2MUlZEV7ZQ6jayQTxpLDKMMrDIIqvo2qy6JqkGlahOLm2vmKaf PKcysyozmCTP3mCIzK/UqrBvmUNI/V9Xi0e2V3WSWSVhHDDGN0k7kHCKO5OCecAAEkgAkTeH fD0lpdDUNRKTapMpRVQ7o7OMkExx5x6As5ALkDoAqr9DwvSxLrOdN2p9ez9PPz6GVZq1nuZH xN+O/h/4RG9m12aSy0zR9PbVdX1OVo4rLRrQb8TTySMoCny5MBNzfIeBkZ+Uta8T+GP2/vgp feKbi103wbJrni248N+HNPvr9YNW1CaAMi/abWXYbbUMxXEoteZTbBRIN5Cx/W3xJ8NeCtbF uvi608OXKXE1u8MeqrEyTS20y3FuwWThnhmAkQ4JRiSuCTn4N/bGv4/2SP2ufEXxF1vStGn8 X+LbKJdM8Svpu+2sLJrhrKLTtN05biKbUtVaMQfapY5xdmKeCO2ikVViT745T528c/CnxD8L JlbWNNkt4JZpLeORvminKHnHfBHIJxnqOhwfC/4iXfwk8cWms2O2WNPkljPSeIkbkPoffsQD yOv2PeabpP7RPw4v9M1GPS7TWrC1sf8AhJtBtNSjvb3wVqVxaRXBs5yvSSJpdofG1wPUlR8Z +PfAl78M/Ft5oWqKqvC2Y5cHY6n7sq99pHUfh1FMD7Z8VeB9C+LfhmKPVbCG8t7iISRMwAlh 3AEFXHKnp0OD7ivJb79oHwN+z9o13oPhWyfUL21O0ugHlTS8gtJL1fHsCOwwOnleg/tQ+KfB nw6/4Rq2eKOSAlIrxstNBER9xe3HZucDp2IZ8BP2aNc+OWrwzCOXT/D6uxvNVlUCG3RVZmYl iBj5cZ6An60gOx/Yf0a9+JP7QGqakYRJctbTXLsowiSSyLk89Bgv+VfYk+r2/g+1NtprrNfv xPeAfc/2I/T3NcHq3iLwT+yd8Mn03SDDYaceJ7oYe71eXHQd2/kB/dFeM2H7fOmS3hW68PX0 FvvIDx3KyPtzwSpC847ZP1NMDpv2vvixq3w48G2a6VOLe81edonuOskahckqT0YkjnnHPfBr 4/uLiS8uJJppHlllYu7uxZnYnJJJ6knvX2/8S/hfon7RPg3S3e6lSAlLu0uoAN2xwMjB7MuO vQgemD4L4i+Btr4k+Px8K2Wi6hoOnWtt5YuIgbnzflYpcyFjgKxwCB/dxwc4APGre4ks7iOa GR4pYmDo6MVZGByCCOhB719KaB+29a2PwtikvraS88URZg8oDZFMQBiZmHABzyo5yDjA5D/F P7COnQeFp20fVNRm1iKLdGtw0YgmcdVwFBXPQZY4JGc181XtlNpt5LbXMUkFxA5jkjkUq6MD ggg9CDQB9A/s5fth69ZfFuKTWL0E6jcq1pIFxHYzH5VTaOfJcfIy5zznOcmvvnxFpdt+0B8O 7bVtOjSHW7DcojZhmOTA8y3Y8cN8pUnH8DdCQfjf9kr4WeFrDwZaeIrB/wC1NUulKyzzIA1m 4xuiVedpH97qQc5wQK9x+HXxy0/4Z/E6DTmv4Xnv4t11p6tuleIH/WhR/GmSQOrLvAB4IAPE bH9kDQT8StR17UZJbjT5JjPHp0wKiKTJMglJ5IDZ+U4x0OcEV2Efi+P4k+FNYs/BWpW1tdae ws47w2xa2jOBny+zYXIBGQCBwRjPvnx4+HkLwt4s0orcWV4iyXwjIeMqVG24XH8OMbscYw3G GJ+Mv2wtR8QeA/DdjpuiQW2l+ErpDDMbOPy2MhJJjfHCow5GMbjuzmkwOO+JPjDwz8Jr+0h8 M3Fxrfi+wuxdXeuyzFld8ENGeTvUgnKg4HHLHIrK+Nf7U+sfFa3+wWiNpGkMgEsEb5e4OOd7 cZXPRRx657eWVufDjUtI0jxvp1xr1k1/pMcwNxCGIyvrx1wedvfGO9AHU/CP9mjxB8WrCe9h VNO09I2MNxcKQtzIBwqjqRngt0HPU8Vwms6NdeHtWuLG+gktru0kMUsTjDIwPI/+vX2H8U/2 mvDfwr0C3j0+S21S9mgR7S0tWAjSMrlGYjhVxjA6kYwMc18m+NfGWqfE/wAWT6pflbi/uyBt hi2gADAUAc4A45ycDqaYGJUlrdS2VzHNDI8U0LB0dThkYHIIPYg1HRQB23ir4keL/j9rFjp8 8lxqEoCxwWdsm2NmAwZCo43HkljwMnoOK9o0r40xfsz/AA2t9A1bUIvEfiO3yI7O2bKaeuBi KST/AGTngDIzjGADXz58PPHl98NfF9nrGntie0fLISQsyH7yN7Efl16gVfa0l+NfxYePTbSx 0mXXbotHAZdsMJPJ+Y9STk4A5JwAOBQB9FfBb9r20+Imu6ZompWJstSvEdWnVsQNKD8qKCSf mXPJP3uMHOa8A/bU+HLfCb4yNqtoTaWWtN/aNpIowIbhWBkUYHXdhsf7dep6gvw+/Y0sUudS mTxH4y2BorcYLQtjOVXkRL0+Zssc8cZx88/E34veL/2qvGdtbG2e8kVyLLTrSMlLfOASO+Tx kn2r9M8PMvx9PEvG8vLQcWpOWia8u9n12tfU/JPE/M8uq4RYBS5sQpJxUdWn1v2untvezsfY fw3+Lx+Mnwy0zV5pBb29zGsNxbwktLPOOHQ4GcE9EXkgjJwStfWciwftKfA94Vgaz1azK7oG YRmG4jAYISp4R1IGQThX7kEV8g/scfs/X/wP8BzDW5I5dW1CczmJTvSzUqF2g9Nx2gsR6Ac4 zX0H8LPHX/CvPGUd5K4TTrxRb32TwiZJSX/gDE5J/hZ++K+Fzijh6eOqwwkuampPlfS3/A2v 13P0XIa2Kq5dRqY2PLUcVzJ738+197dL2PkP9ojx/wCNNZ8cSeBNJ0ubS7X7sVrZriW6jzj5 iMbFBDBlGApDBicV0Hwd/Y20/wALpFqvi+SC9uUAcWWR9mhP+2f4z7fd6/er68/aD+HC6D4h bxDaQILfUiI7nC48qbsxPZX49t4zyXr86v2ifil4r8TeNL7SdckNjFp05RbGBiIVxyrZ6uSM EMfXgDpXmnrH0T+0B8VfCPgjwbeaHqypeyXdv5K6ZbbRIFI+U+kYHBBPIwCAcV8rfDP4u618 I9QvLjRZo4mvoTDIsq+Yn+y+OhZecE8cnggkVzdzdS3txJNNJJNNKxZ3dizOT1JJ5JqOgD2r 4Zfs1+JPjhqI1/xRe3tpYXeJPPmO66u1PI2A/dXHQkYxjAIr6Ak+A3hqP4cXnhi10+G1sbyP DyKu6UyDlZWY8swPIyfbpxXlP7I/7QVlZ+F7jw/r99FaDSozNaXE7hUMI6x5PdSeB3BwOlZ/ xq/bSm1DztN8Ih7aHO19RkXEjj/pmp+6P9o8+w60Acp8M/iPqf7KfxF1rSdUtpbu3AMc1ujb Q7gZilUnoGBHOPut0JAFcb8WvinffF7xc+rX0NvbsEEUUUSACOMEkAt1Y8nk/oOK528vJtRu pJ7iWWeeZizySMWdyepJPJNRUAFesfsn/GgfDTxp/Z19Ls0bWnWOQsflt5eiSc9BzhvbB/hr yeigD9HKhv8AxTb+C7f+1bq9h0+KxYS/aJHCLGQcg5PfPQd687/ZO8ZXvjL4OWUl/JFNNYyN Zq6yb5HRMbd4/hYA475AB712XjnwDpXxI0L+zdYtRd2glWYLuKlWU8EEcjjI47EigDhP23vH d34V8JeHPHWkRa1rVpZW7z6HbxQRSaNoWuRzW0iXFvY28BF3qF3FcXjWz3bNDFPbpsXzJQJP QfBvjS2+JHhudJNW8Eaz4j8OO2l+KoPDmpWt3FY3SzzxxmeCGWT7K88MaS+Sx+VndMsVJqfW fCusXvwS1jw34I1a38O6i5tlS2N4NPj1KyTek9mtyY5Ps8jRvlJAjYdVBwpY1Q/ZL/ZZ8ZaV ocOp+MdU8KnxN4I8HL4P0zwt4N0WXTfDdpayrBcqxnlX/TbgmKJleIpBCxZRGCzswB5d+1V8 Wb74baLDoNhplvaafqls0RvHjV4wmNrRRxdNwBH3uACPXj5Ue6IRkiBjjbgjOWbnPJ79Bx04 Hfmvur4v/DWz+MPgC502UBZmXzbSZlIaCYA7Tg8juCPQnvXwzrejXXh3WLqwvYWgu7OVoZY2 6qynBHv9aAI9P1CfSr+G6tpXguLdxJFIhwyMDkEe4NfcHwZ+J8Pxn+H1tqURSHUbc+Xcxg8R TKOuP7rA5+jEZyK+Ga739nb4wSfCDx9FcSsx0q/xBfIMn5M8SAf3kJz9Cw70mgPfvj5+zbB8 YpJtcsZ3tNat7VoTb7QUuZEOVDHscZXPcFT0HPyPcW8lpcSQyo0csTFHVhgqQcEH3zX6FvcR x7L+F1e2mQGRl5DKR8sg+gPPt9BXzj+2V8EJLDW4/FGk2rPBqMiw3sUS5KzscK4A67zwf9rH dqExsxv2P/jUfA/ikeH9QlI0rWZAImY8W1weAfYPwp99p4Ga+ta+Wvgz+xhqGvmDUfFDzaXZ nDrZJxcyj0Y/8sx7ct/unmvqGJI7G2jjBYJGFjXcxZj0AGTySeB3JNMRyPxw+EFr8ZfBrafK 6W95A3m2lyV3eS/cH1Ujgj6HsKT4Dfsxaf4GuY7PQtOl1vX3AE19JH/qQe7NysMfBOPvEA43 kYr3HwB8AdR8S7LrVzLpVgSCIcYupx7g/wCrB98t14U4Nb/iD4vaH8M9NbR/CljbXU8bMrMh ItoX6Fnf70r56gHJKkM6nmgBmieAPD/wP0+HW/E97FfaqWAtwIyUjkx9y3i5LPjPznnGT8ik gZFp8cJfFHj6zuNStorLRoCwtoSwaSCRhtE0jdCwUsu1flUO3L4Brxr4v/G/TfAm7V/FOqyX mp3CbY0OGnmAP3Y4xgIgPphc8k5OT83at+2t4gv/AB7ZX8EMdpotnKS2nqdxuEIwd792xyMY AOODWOIoxrU5Up7SVhptao/Uuo7y2F5ayRElfMUgHup7Ee4PNeffs7/FS1+IHhK1jiuFuAtu s1rKP+W0BAx+K5AP4d816LX5PjcJPDVpUam6/FdzthPmV0Q6fdG8s45GAVyMOB/CwOGH4EEV NVFruLSLu4M8kcNu6+fvdgqrjAfJPAH3T9WNedfGH483GleGr6LwnFHe6oqERzyjEcZ7lVP3 2AzjOFzj7w4qaOEr1oylSg5WTbsu369lu+hnicRGjCU5Xdley1b9EXPj/wDtIaT8DtKEbBL/ AFy4XNtYq2MD+/IR91fTuxGB3I+J/HnjzVPiV4nudX1e5a5vLk/RI17Io7KOw/rzVHW9ZvPE OrXF7qFxPd3ty5eaWVizu3uTVSvy3Ns4qYuXKtILZfq/P8vxPwXiHiXEZpUs/dpraP6vu/y6 dblFQ3vmPGI4mKSSHhsZ2gc5x+n40V4yXmfPRgmrt2P0b+HHxEHjaC9gubN9J1zR5vs+o6e8 oka2cjcrKwxvidSGR8DcMghWVlXwr9sL9mu9v/F9/wCPNIfxlqcuq2celahp/huaRPEd/Hvh S10nT7zekek6c8xae7mXa7lVLyqiAD2H4pfDvUr/AFa18UeF54bTxXpcJhCTErbavbbtxtJ8 chcklJACY2YkAhnVtv4f+N7X4jeFkvY7eS2kJe2vrG5CmWynX5ZbeUDI3KeO4YEMCVYE/wBG YHHLCf7VQV6UmlKPWD8r9HryvW60burn9Nyjze69zxn9jH9pLWPFfgu/8PeOrnStR8SeC75d BvvEWl3oudN166ihD3bROYYC72sh8m4aOMxpICSUIlSL3nU9Wg0mJGmZi8rbIo0UtJM2M7VU cscAnjoASeATXwd+1h+x94m+GHxL03WNGudWl+HVrrNpfaZY6GHvNS0kQGyFn4f0XS2Q21jL JcW7P/aMMltHHC8ouVkCiVfpP4EftNXnif4iXXhDxH4El0f4pWlpLea1Z6TqqazpWh2/lxvb Ca9+UQGctsSAxpK7QyyCIwqJm9XGZDh8VUWJpy5YvV26+a/UiNVxVmeyeG9BlN62qX8apeyJ 5cMOQ/2OM4JXI4LsQCxHHCqCQoZuX+OP7SXhz4IaDcXOpajZwSxZXMhLKj4zsCr80kmMHy15 wQWKKd9eC/tZft3aP8ItSvdFiii8W+LYw0UtqzMukaUTghHTOJnHHXnOfmT7g+DviF8Stb+K WvHUdcvXu5wNkSBVjht0yTsjjUBUXJJwoAySepJr1sE70lDDx5YLZvdrul59362ZnLe73PpP U/8AgqTrEPxch1LTtHgfw6X8u9iulVr7U4ug3SD5YtuSUjQbQWbcXLEn6X8B/Gn4cftCW50z wpqoN3b2P25dNjt1iubF2jdRLaiUeXFdxM5+ePK5fDZBVl/Ler/hjxPqPgvX7TVdJvbjT9Rs ZBLBcQOUkiYdwR7cEdCCQeKmtlUedVqEnGa673/xd/67Ian0ex9R/tF6jZ/sdePPDdxpKeFt MtE0s+H/AAdBdwT3VnZaNd6tpaazqGoOZ7e61DVXu3t5nhWTdGkM0paWZmEmn498HaB+1jd6 p4eLR+HPiJ4A0zSdQ8WaRHuvT4Sn1CJZP7OkuQBDcMPnx5cjEBQxxu+b2n9lv42D9qL4TW+p 61p9lDPa6nHY37LFDIYb4qqwahbKyt5cwd0GGXAyWB+UhvBtU+F/xn/Z7+Kfhn4b+HrNYfCu i3f2qz8RHzrTTp9LijsZ9V1nXLjz5YdQuridruOS2ntopjJdCWCZQs0w7MJiPaxd1aSdmuz/ AK1XkTKNjoPDf7CXhTWNX0y6f7UmnaRD5d208v7u6YHKtIeMnqNq4BG0cAYNr9pr9pnwt8M/ B0/hDTLG1vYpITAdOTCoykY3Tlfurjog5xjoMEdF8X/HWr/FX4B2Oq/D1hpD6lo9prUOkXIR NUsba6VniM8IYtDLKikoZAOQy8OG2/Ad9NPPeSvcvK9w7kyNKSXLZ5yTznPrXSST6rr17rYt 1vLu5uVtIxDAssjOIUHRVyeAPSvVP2O/hhpHxD8ZX8+rwpdx6TEksVu7DZI7MRll/iAx06ZI znpXj9bvw4+IOofDHxda6xpz4mtzh4ycJPGT80bex/Q4PUCmB9/RxrDGqIqoiDAAGAB6UuBk nAye9ZHgPxvYfEXwrZ6vp0m+2u0zg43RN/EjejA8Vem1uzt9WhsJLq3S+uUaSKBpAJJFXG5g vUgZoAZr3iCy8L6TPf6jdQ2dnbrukllbaqj+p9AOTXxV+0P8RdH+J3xCm1PRtPks4iojklc4 a8YcCQr/AAnGB1JIAJweK9b/AG5fBGs3lpZa3DdXNzotqBFPaD/V2rkkCXA67s7cnkHAzg4G F+zj+xVq/wATb63vdZs7yCxbEkdlGh+0XS+rY5jTkcnnB7cGgDzH4bfGbXvhRBqMej3KwrqU Wxw67xGwPEig8BwMjJyOehwK6D4E/Cjxh8ZPH8Gp6bNeRzRXSySapJukbzdw4XvI5Jxt755w DXpHif8AZ6+F3gH4qeIIfEHim5gTRvDMfjePRbFLef8AtDT5JZoo4raU3Aa4kaS3l4iUoimL zJUMi11nxP8Ajz8QvhN4r03TPh74a1PwLaeCnhTW/C2qZOo6jNPunsZCdM0zVluLG4itruBV hltWEySq0ok2UAeuaN+1Ze+CdGs/CXg6fwR488Sa/r7eF9NtpPEsEdjpGpf2fe38sN9JbieS EeXZuRD5ZlLPgALuaOj4Z0jw9+0/8L7ya3s5bHTLi01C11PTUDXS+HtV06cW1/pss4+RZIrg N5T5IkEbMo2KrN5pov7M3hH4YCHSvH/iK80jw5qGgpo+ieBrnxBqetzaXLMtrJbkpeTy2cM+ nPEUhmtolJJ3M4yVPvv7H3wb8EfDzwR4m8D2LXtzJ4hvRrN5PcW1rZfbJFtba1VoILVEhgEM VrbIqouf3ayMzu7sQD85viz8Mb/4S+MrjSb0F0X57acDC3ERJ2uPfsR2II965mvvL9qv9m+T xVpl1oV4EXWdPBuNLvCNqXCngH2VsbWH8LDPIClvmX4O/sn678QNWd9XhuNE0q2kaOaSRMTS spIZI1PoQQWPA9+lIDI/Z1+Ftj8WvFV9pl8moqDZu0FxbrmK2lx8rS/7PXAyMkYr6b+C37O2 i/B6yEsarqGryKVlvZUAIB6qg52L+p7nsOj8K+G9C+Fuj2Wkaelrp0Mz+XCjOBJcyYySSeXf AJ+g9BXOfGH9o3QPhFE8E0v2/VyuUsYGBYehduiD68nsDTA+b/2r/h3pvw4+KjQaWPKttRt1 vTAB8tuzO6lV/wBnK5A7Zx0xXmddJ8UfiZqHxc8XSatqCQxzOghjihUhY0BOFGeSeTyepP4V n6tp9j4DtfP8RTSQ3Tpvg0qHBu5s9DJ2hT3b5jjheQa68FgcRi6qoYaDlJ9F/Wi83ocWYZjh sDReIxc1CK6v9O78lqRaH4cu/EMkoto18q3XzJ55GEcNsn953PyqPqeegyapa58TdN8EsYvD jDUNSj+9q00eIYGHe3jYdQekj88AqqnDVnXeu+I/jdqcWi6VYGOxjLSxaZYgrbW6jkyysx+Y gAZkkPbt0r6A+E/7JXhL4R+EIPFnjrWdPvrmaITWiRsJbSIlcqUXnz3GQRwV46Y5r9Fo5Ble RQWIzmSqVd1TWq+ff1dl6n5biOJM44jqPC5DF0qO0qr0fy7eivL0PJ/gf+yj4q/aE1U6nfSz 6bpM7iWfULvLz3IYnJRSctnB+Y8V9pfB/wCBHhv4I6KtpolikczLia6k+aec+rN6Z7DivlT4 V/HTUfAXxVXW7q7uL+2u2EF8H4MsGcAhRwCowVA4GMdCa+17C+h1SxgureRJre5jWWKRTlXV hkEexBzXzGfcW4zM37NvkpLaC2+ff8uyR9dw1wVgMoXtYr2lZ7zlv527fn3bJaCAwIIBB6ii ivlj7E9X+CHiu28ZeGLnwdrAWYw25W33E5ntuBtz/fjJAz1wUOSQxHxl+2n+yNrOneN9b1ez nutRuoBCws/LLyTwYKiWLBPGAMoBwwkx0APvdjqFzo+o219ZS+Re2UglhfGQGAIwR3UglSO4 YivXPGmlW3x3+HFrrmlRBdX08MVhLAuGGPNtm7ZOAVPAyEOdrHIB+cHhj9i3xfrbWD3gs9Lt 7oFpjLJvltlGMZQdWIJwAeMHJWu08b6V8L/2edIgsZdOi8S+IbZxOIpX3uz4IHmkfKic52EH PB2nrVv9qT4+69oXiSHwv4bLQzXUCPJNAjtdkvkCNQR8pxg5XLcjlSCKyvg7+xhcapKuqeM5 JYhI3mCwSTMshJzmVx0z6Dnnkg8UAeGeJrq58T6jf64dPS0try7bd9njZbeKRstsUnODjJxn p7VlV98eK/hXo/in4eXHhr7LBZ6dLFsiWGMKLdhyrqPUHn35z1NfDXjDwpe+B/E17pOoRGK7 sZDG47N6MPUEYIPoaAMyiptP0+41a9itrWGW4uJ2CRxRqWdyewA5Jr3f4bfsP3usaDPd+Irx tNupoW+y2sWGaJyPlaU9MA/wrz7jkUAeBU+CB7mdIo0Z5JGCqoGSxJwAKteIdAu/CuuXWm38 LQXllIYpUPO1h/Me/cVTDFSCCQR0NAH2t+zt8CR8FvD0vn3k11qWoqj3ShsQRMAcKg74yRuP J9B0r0WuG/Zy8a2Pjb4TaXJZvKXsoxa3KSyGR45VAzknJIOQR7EDtXc0AFdv8HPiVe6H4ysN PuLm5urHUSLRYGZpDC3OxkXnAByGxgbTuPCCsLwN8PtU+It4U0+MRWkbbJr6VSYYiDyoAILu P7oIHqVr0tpvC37PFiyRq2o69cR88q13OCeNx6RRZHsPlOAzdQDl/jt8MpPCurXWv2kaf2Rf SiS5VSd1rO5wz4xjy3bBJ6h3JPByPkD9tH4KjULH/hLtOiHn2yiPUUUffj6LL9V4B9selfbn w5+M7fEDX7zQfEVrYrBrEbLaIikxuNh8y3fd94lAWBwNwD8DAB82+Ivw+bwR4gutDvFN1YXM bNaPN8/2q3PylWz1Zc7W9QVb+LAAPzSoruv2gvhDL8H/AB9NaIjnS7zM9hIcnMeeUJ/vKeD3 xg964WgD6e/Yv+NI1nSz4S1KYtd2al7BnOfMhHWPnuvUD+7n+7XudkBaSm0YEoo3Qk85UHp9 VOPwx3zXyl+zv+zb4l8R6/pmuO91oVpFMktrIsZe6u2zwsUXU7umSMEHgMMivvvwV+zvJq0U eoeJ3bT7OA+ctosuyUgA/NJIp+QYJ4U5x1YcrSaHc4/wh4M1Tx7fm30q3EqxttmuZCVt4PUM 2OW/2Vy3IyAOR6nZeF/C3wFtI7/Upzf6vJnynZA0znGCIY84ReeW7Z+Z8YrnPiP+09oPw88K y2/h2TTrDTbEGI37oI7S356RJx5jZzg/dJII35Ir4i+OP7bV/wCJbq4t/Dc92DPxPq10S11c cY+QH7g647gYwFximI+mvjj+2Vpn9qDS9Y1m30O0nVm+wQs0kjoFzmdkGecEBOAc4+frWP4C 8c6Z8RfDFvqukymWzmJVcrtZCpwVI7EfyxX5/wBzdS3txJNNJJNNKxZ3dizOT1JJ5Jr1X9lH 41n4Z+MP7Nv5iuiaw4SQn7tvN0WT2HZvbB/hoAxP2kvAuq+B/ilfLqVzc38d8xuLW7mYs00Z PCk+q/dI46A4AIrga+4/2gfhDF8YPAU1oiINUs8z2Eh42yY5Qn+6w4PbOD2r4hvLOXTryW3n jeGeBzHIjDDIwOCCPUGgD6D/AGFvj9P4L8Sw+Hbi4MayymbTJG+7HLg74j/suM8epI/ir7O1 v496pfqUsre309WH3v8AXSKc9QSAv5qa/Ky3uJLO4jmhkeKWJg6OjFWRgcggjoQe9fbv7O/x fj+L3gGG4ldP7VscQX8Y4O/HDgejgZ+u4dq5MRgMPXmp1oKTW1/6s/mNNrZmP+1X+0R4o8M6 3pmm6dZ3l/qeohntrubMyBjlWjijHVhwccAfLwad+zZ4P8a+H4tUv/Ft+0zauyTLbSv5k0Tg Y3Eg7VBXA2DONo6YwfR5YkuNZiYqpa1jLAkcgucDH4K35j8LddEIqK5YqyQrHkfx08CLpl4u r2kW2C5bbcBRwj9m9gf5/WvO6+mNW0231jTJ7W6QPbzoVkBOOPXPYjrntXzp4g0tdG1ee3jn iuYEY+VNGwZJUzwwI4+uOhBHavwbxJ4bWExKzKgrQqP3l2l3/wC3t/W/dH5Fxnkn1av9bpL3 J7+Uv+Dv63MxpljuiZDs42oTwD3PPTPt14oqaivy+58S2j9EPhd8Rf8AhO9Nure8txp/iDRZ RaatYHObabGQyE8tDIPnjfoynswYDI+IVrN8MfEcvjbT4pZrGRFj8R2cKF2mgUYW8RRyZoRw wAy8QI5ZIxTfG2mz+IbLTvHPhFBc65p8P/HsJBGNYtckyWUhztDg7ijH/VyDqFZwev8AB/i2 x8deGrPVtOkaWzvU3JuQo6EEqyOp5V1YFWU8qykHkV+9xrUopY3DK9Keko3utdbX7P4oPV6b txbP6gcXfklo1/X/AA5f0rVINSsoLu1mS5tLqNZYpYnykqMMqysOoIIIIr8/fjj8NvC3/BNH 4mat4k8O6doWm+IviD4gsLvQvEWqpPftBAh0mwv45jJcRyahq84vNSugrSGSaK3wN7R7a+wf D+Pgx8QI9BbEfhbxLKz6MedunXmGeWz9o5AGliHQESpwPLWtT4/aR4t1/wCEep2vge+gsfEo mtZ7czSLEtxFHdRPc26yMjiGSa3WaJJtp8p5FfHy17OUYv6pXWHcr0qmsW9P6d1ytbXWmmrz qR5lfqj4q/bG8K6X8ffBUPjnStS8JTfEnwvp1rF8RfDuiaxBqMujTlfLYuIpHK+VKkkZLE/K nX92a+UK+x/hx+zL8TPC3wPgudZutKtPF3w78EXHhfwto/h+yng0uz0S4kiiuXvblCba71SQ WMZeNX8q3IZ0Ql/MPyFquh32htAt9Z3Vm1zEJ4RPE0ZljJIDrkDKkqRkcZB9K+xoU401yRen Rdl2Xl27HO3fUq1JaWk1/dRwQRSTzzMESONSzux6AAckn0rsvg38A/EPxuv7gaVDDb6bYLvv tTu38mzsUAyWdzxnHO0ZPtjmvQr74u+EP2aLZ9P+Gypr3igoY7rxZewArASuGFnGeFHP32Bz /tDBrcRvfBDRZv2MYZvE/jbXLzR7rV7Mxw+FLF1a+1FGB2PPnIgVT8yscODnBByp+w/hD8Wf Bf8AwUE/Z68Q+G9TW8uLTVLCXRfEOn/aZLG6lgmjaN2D27q8ayIW+aNwQdwB4yfyw1rW73xJ q1xf6hdXF9e3TmSaeeQySSt6ljyTXVfAL4561+zx8S7HxJosp8y3Oy5t2JEV5CSN8T47HHB7 EA9qhQSk5Jasdz9N/Cf7M2j/AA/+GviPwv4P8LeFvA9u2oC4tv7Kk3trYEcbeffsYlczvJ5i szNKx2I5kYsUHxT+13+znJK954o0i0aG7t2YavZ4w4ZThpMDjcCPmA6/e9Sf0E+EnxW0f47+ ANN8W+HJvNhukw8TEeZGw+/BIM4DqT/Ig7WOeZ+P/wANk1Ozk8T6ZGZJYo/+JjCqkmeJRjzN vXzEAwRjJUY5KqKoR+RlFeyftU/s/j4faodf0eLdoOoPl0QZFnI2TjjpG3Y9ATj0z43TA7n4 PfHzWfgzDqMWnrDcwX8fEUxJjil6CUAd8cEd+PQVn6H4q8VeMPidZ6pZz32p+JGnV4XUbnJH bA4CAcEcKBnoK5avqz9iPwndaL4Nvby80NLJ72QNb3zjE11EQPlweQgIyCMBs9OMkA9J1v4n 6H4K0zTIPFt4bHV9Rs2uzpun6Xfa3c+XHtE0/kWUE0y20bsA1w6LEpIBYHipv2hfHth8Nvh9 4r0+11/UNFv9H1PTNI8Ra/bTS2EvgVLxFn07WBGyj7bZfbhaxzcrEY0vFfcsM0dReJ7TXvB/ jvWfFehW9jqeleKfBsHhDxFbnxQvhrU9KFpdahc2l9ZXjLtAb+07pJf3iSIY7d492GFeY6d4 I8MfDPwPovh8aNpvxH+JOkXN5e2dtDqd/qGi6FbT6ib6306aSSWM6haWjMTC16GxLiWOOJds YQDvDfw00fw/qS+IviPZeH/hvYXclzDPpd/YNdSy213dXNv4l8Mm3G2e70ea5B1CyuVUoj3C tgRqIpPN/il+0qNM17V7L4b3XijQdLu51juNXvPEl/qWs63BB5kdskt1cSNMlukcjlLcHaGm ldi7uWrZ8RfAL4l/tB3l54r8VahGNbu/LWKG9IRigIGNqDbCigkhQM9eATk+n/CT9l3RPhPa rfzQ/wBu67Eu9ZZAAiOB92JTwpzxubJ9x0pgfKvjnQvEthPaan4ih1RZtVTzYbi9LNJMo4zl ueOODzgg9CK+sP2U/jhP8RfCVuz3bQ+JfDzJumzl3xwk3PXcMqwPB+YHhsV84fHr45a38WNa a01G2TTbTTZnEdiFy8Lj5TvYjJbseg9qwfhT8R7z4V+OLPWLQlhC2yeLPE8RI3ofqOR6EA9q QH6vt9i/aM+HmV8my17TT35+yzbfzaGQfmPR0+X57+K3iK9+H3gnWrwpaWeqaUjAw3r7UWVf 4CR1J/hxw2VIODmuj+FfxOFhPpviXRZftVpdRguikAXUBOWQ54DA9CcbWGDwWB7v9p74R6P8 cPhpJrlskd3ZXNqDeBRtaaAcrKM8rLCeecHAYEEqoAB+ZV/4y8UfFHx1bXputQ1DW2lBtfs+ Q8LA5AjC/dAPPGOmfevWNF/ZV07wx4Ov9f8AiLriadJLCxAM4xbSMDh5H58xwedq5HHVqueM fjX8P/2PtNl0nw3bR674oZQsxEgdgcdZpRwo6fIv5d6+eNR1fx/+1/47WIi51e5BylvEPLs7 BemT/Co/2m5Pv0r7bIuDMRi4fWsZL2NFauT0bXkn+b07XPgOIuPcNgqn1PAx9viHoox1Sfm1 18lr3sRa58XLLworW/hVWe5X7+tXUYWUf9cIzkRjp87ZfrjbnFR+Gfg7LdRprHi68udIsLvM yRsvmajqPuiN91T/AM9JMD03V7Lrv7KUP7NvwwTxDNPZax4oaZIt0sBkgs8gsTCh4Z1C53yD AG4gA4ryXUNRuNWvZbm6nlubidt0ksrF3c+pJ5NerjeLcHltJ4Lh+Fu9R7v0vv6vTsjxsv4K x2a1lj+JqnN2pp2S8nbb0Wr6yNTUPFqw6U+laLaJoeisRutoXLPckdGmkPMjfXCjjAGKs+E9 C1b4r6xpeg21yZrlAYbVLm42xRR/M7Yz0xycLknsOObfgf4DeMfiNBbXGkeHtSuLC680pfyR eTYqsQzKz3D4iRUHVmYAdOvFesfD/wAA+HfgUp8TXGl6Z8Tl8KeH7Xxz4iudO8SCKy0rQpbi 6ha50826udRuYfsNzI6CSNFVUUF3kUV+dVq9SrN1KsnKT3b1bP1LD4elQpqlRioxWiSVkvkc 78Sv2Ntd8HaVDdaZINYjgtHnvioCGN1OSEU8sCp4HUlT0yBXX/sU/Gfz4G8H6jMN8QaXTWY8 svJeL8OWHtu9BX2xb2/wtn8NXN5Logv9DkMKWt5dWkt/a6tHPbJPHLbO28SxlHx5g4DBhkEV +eX7SPwwn+CXxPj17QIZdO0i9umutOVW3GwYOWEJPQkLg+h5HIFYmx9fUVyvwZ+KFr8W/Adp qsBVLjHlXcIPMEwHzD6Hgj2I75rV8TeOdH8GtANW1Kz043QcxefIEEmwZbGfQY/MUwNWuw+B 3jRvB/jiK2kfbYa2628oJwqTHiKTHqTiM4671JOEr44+NP7ac1+JdO8IB7aLJV9RkUeY46fu 1P3R/tHn2B5r2j4H+ILzxj8I9FvtQu4Lq8ngG+4tpCSSpIDE4BWQYGcdGBxQB6r8fPhpY+G/ i3/baafAJdXty0VyUUujhj5sYPVQSyv/ALRkfrg45mvVfH3iAeNPgWsFzcWUninTbS01K+tm IintwjoJ5vKzuVCnnbTjBDcEg18hftZ/Ezxd4KXTtO0C3MNtrAMQvIFaS5MoP+qQD7pK4IPJ POMYoA6n4xftF6D8IIHhmk+36sVzHYwsNwz0Lnog+vPoDXh3xdgv/wBoXwG/j230/T9Ng0WI W1womL3F0QV3noAFQt8oPzEE+wrB0j4a6d8OPFMFz8S0u1iu7Nr+K1gl8ya4k348uXB3Kxzu 6j3YHIrorH4p678fNcHhLRdGg07wncKts9tb2azfYYd6nzy3yhWG3I5AGTgFsGgDZ/Ye8SeH rVNUtLm2tLXXIFa5F7IcGS3AG4Anhdp5OMZBz/CTWr8bP2z7bR/O03wiY7y6GVfUXXdDEf8A pmp++f8AaPy/7wNeS/tE/A+T4LeKYUtnnn0i/TdbTSY3AgAOjEcZGc9shvrXndAFvW9cvPEm qz31/czXd5ctulmlbc7nGOT9AB+FVKls7ObUbqOC3hlnnmYKkcalncnoAByTX0p+zF/wTw13 4qX0N7rcRtNPjk/eRliFTHUOw6t/0zQ57M0eQaAKP7DXgzW4bu41mG7hGkagxsjZRgzT3cw5 XCLyrLnjqSGPGDmvtzwJ+z+XtTqXit1tLWJTIbESgAKOS00gOAMDJVTj1YglaZc3Pw1/Yk8M 2UUrWdtqN3i3tY8ILm4Zjjag4EcZI5PA4ySxBNeOftPftZP4YsILrXhNKbkk2Ok2u5YGZCDu ZyMMVyvzN04KqKANz9pT/gpF4e+E+pReGPC8ElxNAUhuLmCJUSyi4/1SsNpO3lcjGAOMENXz z8ff2tb221c6R4ScXFzeKksmqFxcy3DSKCuzJJL4IBL5bPGBgGvPfG8msftH6Bqfi5NKtLWf w+gS5+zpKTdxFmIIyCpMS9eckc8AAV1H7FXj/TI9b/sDUbSx+2gvNpl20KiVSwHmRbsZ5Cgj 6EegoA+g/AOq6n4k8E6Ze6paXGjau8aSyICFlt5lPEi9dpyAwB5GQDyDXvdnNB+0b8MJLaZo bXxHpLDL7TthuAp2yAdfKlXII5wCwzuXI+NfGf7aOj6F45tNL0+2e/sUuBFfXnKhBnB8terE HnJwDjAznI958G+MbjwL4kttasg0youy4hX/AJe4Cclf94feX/aGMgM1AHAfHL4Rr8WvBF5p F3CLLV7J2MJlHzWlwvBRiP4T0JGQQQwzwaofswfsAxF4r+aODVbyI/NfXKn7DbNnBESdZXBz yeMjqhr631r4d+EfGlxH4wumWSxns0upXMvl2l1EE3LLKOMgJ6kArgMCAMcH8X/2qbbwx4du pNJcaRo9hGBJqMsOHVc7QIoiPlH3QCwz1ATo1AHVxReEv2frcNK7X+uzR9doku5QfQdIozj/ AGQdvJZuvmHjL4rX3xVmnS5urcWNtL5Z0+2kDxROMHEp6u4yD8wAHykKDyfjn41/tjan4zlu rTw8bnTLO5Yme9kkLXt4fUuSSmfqW46gcVgfsx/G1/hV448q+lY6Nq7LHdliSIWz8s34E8/7 JPUgUAek/twfDW+vbC18SWs9zNZ2uIbu23Exwk8LMB0GeFJ/3fevmiv0U1HTrbXtLmtbqKK6 tLuMxyRsNySIwwR9CK+arL9hm/u/H1/DPfraeHYZc284w9xOhGQoXoCM7Sx7jIBoA8X8E+BN W+ImuJp2j2ct5cvyQvCxr/eZjwo9zX1H8E/2RdJ8ArDqGuCHWNYTDqpGba2P+yp++Qf4mH0A IzXoPgnwho/wy0hdP07T4dMgHLOvzCY/3nkPJP8AvY9BxXQ0kx2Cvmn9tP4Kiyuh4v02HEU5 EepIowEfgLLj/a6H3we5NfS1VtZ0e28Q6Tc2F5Ck9peRtFLG3R1IwRTEfnZXZfAz4s3Hwf8A HdvqKF3sZsQ30I582Inkgf3l6j3GOhNQ/Gj4X3Pwk8e3elSh3tifNtJmH+uhJ+U/UcqfcGuT oA/Q3w5ew6xYf2hbyLNBqB86J16PHgBSD3BADf8AAqv185/sVfGjereENSm5UGXTGY9RyXi/ mw/4F7CvoyklYD5A/ad+Lni6/wDGWp+HdSlXT7C1k2ra22VSdCMq7N1cMCDg8D0Bqp8EvFJ1 nRptAmG64sVe7sn9YxlpYj9OZB/209QK+gfj1+zpafGy40y4+1/2bd2TFJZli3mWE87cZHIP Q5wMtwa8D8YfEPUfg1dNpHhzQJPC0KuVa8u4RJfagEkw26QjaU3qRtT5fcg15+bZZRzDCTwd de7NW9H0a809ThzLAU8Zhp4aptJfc+j+TOlopYNTt/Eel2urWapHbagpbylbP2aQH54j/unp nqpU96K/lHMsvq4LEzwldWlB2f6P0a1XkfgOLwtTDVpUKqtKLsz6z+DHxZuvBvjN9Mvoiug3 igicniCXIG/0CnOCD0A3ZwDn0HXpU+DHxDj1ZQIvDXi26S31IZxHYX7YSK59lmO2J+2/ymx8 0jHwzWLa5u7Ty7WdbaRmAZyu4he+PevWvhlqj/FL4f33g3ULNdWV4PsU0k0Za3S3dCCZSCOQ BhVBDMSuCAruvZ4Q8UyxFSOSV1zXVkle/KrXvfRNfFHWys07Kyf9j8T5bGMVjKdl3Xn3+ez+ 87/4l+G9M8W+B9QsNXn+yWUyAm5Egje0kVg0cyMeFkRwrKezKK5z4TeKNZ+Jsd7o2rXU+haz 4bMSXzW8KJNqQfLRXKJKjCO3lRScY3h/MTKGIl6fwkvn8GNcaH461ObWfFXhbyo7SVoQBqdu 4YQXUEK5JlcI6yZLMjxy4IQgmH4z2mtx6rpvjPS5YdN8UaYDBZaUhVn1m1LrJNaTNyHYhAyb cCNwfnKszV/SGDyjC4GSwuZTUnJ+52Tdknr0krXvZLR9LHxTnOetNev9eR6PD4h0nwXewaND BcwxI4EkuCY4XlYlTI7Hcxkct83zZY/MQTz4Z+15+zr4R1zRrW98TWcz6V4WgnvrF7a4jtXk gRMtpzyOQNpbaY8EEKGAxgs3rFxqel/GD4d6V4p0zzLrTdRtRJPEmd9zaupEkTAc742JOBlg yOowWNL4j8Hab8cPhvqvhLX/AC71J7cKJ8KxlRgfKuVIwN3BzjHzK2AFIz6dZWr+wqK0ldx0 a20a33XVdraELa62Py3+Mf7Smr/FPT4dGs7a18N+ErE4s9E08FIEHZpD1lf1ZuM8gCvOK6z4 2fCPU/gf8SdS8OapEyT2MpCN1EqZ+Vh0yCP84xXJ13pkBRRRTA9w/YZ/azu/2ZfiZGl5JLN4 U1p1h1O3B4iJ4W4Uf3k7/wB5cjrgj9SotWgeGDUbedZ9PvlRvMQ7kwwGyQEfwkEAnp0PABNf iXp2oTaTqEF1buYri2kWWJwASjKcg8+hFfqV+xd+0pZ/HX4fW73AhE90zW9/a8FbW8KlnXae kUyhpEzkA+YmeFFY1KvJOKa0el/Povn+enUaRk/Hj4P2fhe/nsHtYpPDevK6QwlfkhYgl4PQ DGWTHQAgAbMn8/vi98DtT+G/xGGi29vcX0V++7TWjQu9yhPC4HV16Efj0Ir9b9c8Gw+LPC15 4e1F5HjZQbefJMiqCDG+T1dGAByTnAJ+9ivm/wAT6Bd6Zd3tq8VrFrenCSCN5Yy6RSFRg9m2 N8rcYJUithHhfwE/Y/tvDfk6t4rjhvb8fNFYnDw2/u/Z29vuj37d38Zv2gtE+DFqsNyWu9Vl j3wWUXDEdAzHoi5/E4OAcGqHjD9om1+E3hCzHiVbeXxS8IMum2Mm/wCb+8W6Ip4POTzxuxXy 78SvinqPxs8Y293q8tpZxgiCIKhEVrGW6nGWbGSSeT6DtQB0V54r8XftZeO4dKN3bW8TbpYr XzPKtoEGMtjq7Ac9z1xgdPqX4R/DC0+Evgu20m2dJ5I8tNceSsbzsSTk4HOM4GSSAAM1gfBT 9nLw98K7aC+gKatqrpuGoOARgj/lkoJCgg9QSSD1xxXo1ABRRXlnxn/aq0P4YCWysimsayuV 8mJx5Vu3/TRh0IP8I59cdaAPCv2xYEh+NV2U0t9OaSGNmk3hlvjj/XAAcf3SOeUz1Jryuuk8 ceP9f+MnidLnUJJr67k/dwW8KErGP7kaD/65PcmsXWdZ0fwDvS8Mes6uo4sIJf3Fu3/TeVep H9xOfVl5FejlmVYrH1VRwkHJ/gvNvZI8vNs5weW0HiMbNRj+L8kt2/Q+kf2YfHFj8J/gZdaz 4i8Q2EOjSXLm3tzky27rw6c8kt8pCqCBnOfmOPP/AIp/8FKfF3i3SLzwl4NkutF8PX85VXVi Lycv8rKpH+rRjztXBJZjnmvE9O0TxP8AHrVXndkNlp4/eTSbbbTtLjJzjsqeyjLMegJr1T4D XHgP4VePtNW5tP7cMreXcavdqY4rViMBoYjyFDdXf5scgKRz+hQy/J+HIqpj2q2I6QWy/ru9 eyPzCeaZ5xTJ0suTw+F2c38Ul5W/KOnRyNP4Wf8ABNXxRqCaVrPjRLjQNC1PdJFDt23lzjB2 kHIi3A5BbLEA8cZr6s8BfDvRfhj4fj0vQtOt9Os4+Ssa/NIf7zseWY+pJNe/6DNH8efg+9lP On9s2GEMrdUuEH7uU4H3ZF+9t7M6g5Bx44YZILiWC5VbSe3Z0nWd1jW3ZM79zE7Qq4JLE7cD Occ18ZnvE2NzWd68rRW0Vsv835s+94d4Sy/J6dsNG83vN6yf+S8l87ixaVJrQkt47V7sOjb4 1jMmUx82R6Y69q+XfiN+y1ovwhl8aeL/ABTc6gngTwppD68dP0qSF9ZvISyoiRxyH93EJH+a 5lHkoiMzsoDMvonjD9oGfxn8T/DkXgPxzHYeEdKhXRvEc17pl7ZP4e1rUGWfw9rUltKsD3Wn TXEUdsJizQuHKhdskskU/wANPhTdfGXxBceKvEnh34f6S1n48n1LxTcTTSy+KNJvhZLb6h4e ki+zeXe2c6HbFPJPGj2NzbHyCUSRvnz6Y5zxn4MFl8a7v4fzHV9LXV7mw8B3Xw/02EreXehl UvbPxJFcHKXElpeSXLXEoXyNklxA6vIkQk6/R/2ObV/Cd9aePfFdxqPis6sLnT7y3uJ/Eo8P xBIluoUm1MfvY7uSITSW4iW1V0ixC5Rnk9RXxMvg7wRpuiafd32k+GfDumxabbQXOpzXHl20 KBF86aVi0rbQMu5JOOTXzj8av20obNZ9N8IYmnGUbUnXMaHv5an7x/2m49AetAHq3xN+J/g3 9m/wN4X0DTZrtdG8K6Nb6JpljPIst/cQwIVWRsYAJPU/KuOgGAtUUl0X9qL4NMQpSDUEIwcN JY3C/wBVPPbKn0NfFOr6xd6/qU15fXM13dXDFpJZWLO59STXpX7K/wAaf+FXeNBZX0u3RdXZ Y5yT8tvJ0WX6dj7HPakkBH8LPiJq37MvxJ1TT723aSP5re6tWk2I8gBMUgbBwMkfNj7rk88V znxX+MGvfFjWTLrE7JFA7eTZoNkVt2IA6k+pOT/KvZP2rP2cr2+l1fxjZ6hcXzLsklspFyYI lXDlWzyBgHbgYBb0rxPwN4E1D4teIbbTNN+zf2g64bzpRGpRR9/3wBggAnocHk0wObr7m/ZC 8M6t4W+F1pYXUGn+GtXkiufsNzMBNHDcPG32e5nQ5HyyFCVORhRkDkDwj9mL4J6D4i8barY+ JhM2s6HKf+JZIAsUig4Lk9XAbtwMFTyDgfVcECW0KRRIkccahVVRhVAGAAB0AoA+dPAUPgf4 WaX4es9V8FWPwd134aHw9rXib4meMLCaxvTrS6iia1p0+pzKBqkmpWXmiJ7eWeOVJ3L+XtgD fRvi/wAPXGl3F9pqXUa3cKE2l6EWRXV0PlXKjlSGU5wMjO5cnBql8abO213wJN4vsPDdnqHj /wALWVpollq8umT69NoOkXF2kN/eWmmgOj3EVtLIzeWm+VVVXEiIIm5H9nLx5Yz674r8GzeN 9T1i5kgSXwJoHiCxg0nXL/Q7OKzV71NMiht1tIY5HvIYVjtLc3EUQbZLsErAHi/hD9kfxJ4+ 8XXt/wCMr6e2t452WWYyCS4vdpxlCchUwOCR0xhcdOh8b/tGeFvgfoj6B4DsrK5u4vledRut 0buzPnMz++ce/GK9n+Ing2L4ieB9S0eSeWBNQhKCWNiCp6qeOoyBkdCMjvXwb4o8NXng7xDe aXqERgvLGUxSqemR3HqCMEHuCDQB9E/DbxbD+1f8LNS8L69PEPEdlm4trkoAW5+WUAY+6W2M B/Cw7njyj4f/ALM/irx74ml05bCaxW2uDazTSxsw8wHBSNV5lfg4CZ7cjINct4D8bX3w78WW Wsae+25s33bT92RejIfYjIr9OvgB8W/AVp8JtL8UWVyupazq0AaaJAJLuGQ/fhCniNFIK7jt VtuSS2KAOc/Zn/4J/aD8I9OGp64mLlYy0plkAm29T5kinEaf7CHoBuduRXdeOPj4lnarpXhC KC1trcCIXvkgRooGNsEZGCB2Zht44VgQa47xz8RtW+Is5GoSJDYq26KxhJMKYOQWJ5kYccnA GAQqnOcOgDzH9qH4Jt8XfCUl5aiS48RWBaeKWRy0t4DjfGzHkkgDbnoQBwCau+H/AIVTeOfh Jo+kePreG+vrIrI3lzEtlchQzr1bYdrEHnnnvXoNFAHB/Ef4reFvgL4XjspUt0KxFbXS7ZVD OPQqOFUnqx689TxXyd4s0CUeK7TVfC9jqttpusTmTSMDEwkUjeibCTlHJA6HABr6i+KH7MGi fFTx7aa3eTT24SPZeQwjBvNuNhLfw4HBI5IAHGM13nh7wrpvhTS7ey02xtrO1tQRFHEgATPU +uT3J5PegDz/AOCvwB0bw5Z2Ou3+iG28RTQKZ47if7SLeQDDOuScMxG4nJILEZHSvT6KKAPR v2ePG/2TUZ/DOoOktjqG6SxWQZCuQTLDz1DDLgeok9VFcX8VfhpF4V1q+0K7gW40i9jY2olG 5ZrduDGc9ShO098bWPLVmlpYyrwSvbzxMJIpUxuidSCrDPGQQDzxxXsmp2yftBfCWG7gSCLX tPY4UcLFcqBviyeQkikEZ7MjEZAoA/H79ty+g/YyvTNqoiOl3mp2lpZ3FzcC2i8iedUeV5CC AIYzI7evlHpkGuM+GHxTvPio2lXdtpEOj6H4gvWi0u/1i8Nn9ps47Sa7mvXUxkQxiGCV1WRl ZkQsdhwp+1/24v2OLX9sHRfCD3U1v/xQmrSa7FptzZCUajcrbTQxQuWYeXskk34IP7yNM421 8OXvwY8Q6d4T0rwtZ+Kv7J0LwhDrFtoNiNIjY6ab5odqzb2InW3VbiJUZR+6mVODGWcA+s/h J/wUR+HOh+GfC/hbS9a8QeN9cudVsNCijs/D99HKouizLNskiEn2eKBJH80rtZIztJw232z4 b/tOeCPi34um0Pw/rE1/fpby3kLNp91Ba6jBFKkUs1pcSRrDdxpJJGrPA8iqZEBI3DP5l/CL 4B6/8G/FHhzVdH8U2lgfDuuXGr2tla6dKLKxWWwez8q1jkncwgCWV8ZaMGVgEGBX2f8AsJ/s sz+DfEem/Ee/8Y2vii9m8KJ4cwun3Mdy0onSW4ubie4u7iSWeVoo9/3V/dqQOSWAPqIjIIIy DVVrF7YhrVggHWJj+7I9v7p+nHsatVU1vXbLw1pkt7qF1BZ2kA3PLM4RV/E9/bvSauNMltb5 LosoDRyp96Nxhl9/ce4yKhj8R2E2uyaWl5bPqUUQne2EgMqR5A3FeoGSPzr5s+Of7YkutztY eE1a2giJB1JgVnf18sfwKfU8n0GOcH9mH4b+LfEfxCtPEdnK9lbW8vmT3l3uIu0Jw6qOsmRk E5wD3BxQvMR7p+0/8JLf4nfDuedTFDqejI91bTOQoKgZeNieArAdT0IB6Zr4sr7r+NfgB/ix 4JvtDhuHtpignRwxCmQZ2I2Oqkg5znHBxnFeG/CD9jK81Fl1Hxg50yxj+b7IsgE0mD/Gw4Rf pz9KEwPMPhJ8PfEnjrxRbnw5BMtzZyLL9syUitGByGZ+gI64GSewNfdmmrcJp1ut28Ul0sai ZowVRnwNxUHoM5xUOh+F7TwVp0Wl2enNpUFugZLZoGgYKejbWAJBwfmPXB5NXKYBXKfFH4M6 H8Xk09dYimcadMZEMT7GZSPmjJ67WwM4weOCK6uigDltY+EekT+D00fT7O102GBw8PkxhQjc bj7kgYJPJ4orqaK8LMeGcrx9X2+LoqUrWvqtF6NHi4/h7A4yr7bEQvK1r3a/Im+B/wAM7/4h atb2V60rWtsolv7hfl2pniIMP426ZHIAZs5Az6v4/wDjNpvwnV9A8N6bZNd2q4dVAjtbNmGQ GVcF3wQxUYyDywJqTxdrtl+zt8ObfSdKKzaxehvKZ+S0hHz3Lgn7oOML/uqMDJHmUTp4FtFu buFL3Xr1/Pxc/vPs4J3b3B5MrNk8885+v4jNw4Lyx5dgKkIYqS58RWcbxpp/DGMesm/dpQ6p SnJJXZ+mylLNMQ8RWi3C9oxWl+78kvtP0Sudh4tGpfF7wLpninQU+yfEDwZmdLfy8C/hdcSw bWI3RXCrlDnAkjUbgUavH/Hn7Rl3e22zR1ngn1G3WS41G4fzLiRXUMFiyB5UeDkAKp5+6pzX S6B8SNU8O+MLfWxNLdzwnbLGzYE8RPzR+gBwCOwZVOMDFWfjF8MdDt/E+n+ILWV7fwz4znAS 8gjBbSbyRvMbg42rKwJxwyytKvzNMir9NlXEq40yKbyqTjjMNpqkpzha7tZtR5tZKz0fNC9p K+dDD0spx8ZYyPNSn6tJ9L97dbrXR2uin+ynruv/AAH1W1tPEFlcWfg7xteFLGWYBfsGoMpb kE7ljuACQSMb0Jz84r3TVtLm8La/b/ZAoBZ5NODHCnI3TWhPZWVd6dlK9MRgFvi/4c6f8Qfh zceG9Wee+s7u2WB52YecWUArMGA4kDAOGA4YA1hfBXxNeeL/AA/qfgfxRcN/wlfhYrBLcoNj 3sI5t7+MHPLAKT94K4KknkV9zklZ47LoUJzvWope892lopP/ANJl30bbcmz57HVVPEzqqKSk 27LZX/q/+SPPP2+/2ZYP2lPhPH4n0C3MniLRYmkjTbtkuIgfnhZT0dSCMHBBBByQBX5myRtD IyOrI6HDKRgg+hr9kdC1+bw3rkpvAIop5lttQUBglvckARzoDnEUo2g8/KducHzCPmf9sT/g nlo+rTeJNe8MQ3Vvr2pD+0LK1Qj7NPJGrGe2VQOJHX94nJyUYYUAsfco46Lpe1mrWdpLs9n8 ut+2pyOOtj4EopSCpIIII6ikr0CAr0z9lb49y/AP4mw3k7ztoWpbbbVYouX8rcGWZP8AprEw DofUY7mvM6Kzq041IuEtmNOx+1XgPxbbeNtItphcQz3UUaTCWE/u7mJ1yk8fYxSLyMEgHIzl c1yH7Rfw/a8sV8RWiZmsYwl6irlpYc8P9Y8kn/ZLdSqivln/AIJoftC2viOCP4b+IZpUubMS T6BdJcPBNsPzS2odCGA43gZwQGB+6or7O0eRvCurJaSzXVxpupHZG9zO87W82MbC7kko46ZO AwxzvUDyqWaKGIWDxCal0fR9n6vt30LcNOZHwb+1/wDA4eM/DzeI9Mgzq2mJ/pCoPmuYB147 svUeoyOwr5Or9QPit8PR8PPExt4YyNLvQ0lnxlUA+9Ef93Ix6qR1Iavhf9q74Kf8Kz8Yf2lY QldE1hy8YH3bebq0fsO6+2R/DXsmZ6P+x98dYLvwtP4e1q8igk0aIzW00zhFNuOqknun/oJH 92r+p/tv6BbeOoLG3tp5tEUstxqGCDnHBRMZK56k4PPTjn5Rr0f4N/sz698WjHdlDpmijLPe TKcuoGT5a9WwB14XrzxigTdtWb3xo/a/1bx352n6EJdG0lvlMgOLq4H+0wPyA+i8+pIOK8li 0+K1s0vdSuV07T2+7K67nmwTkRJwXPBHZQerLmtn4yXXhTwP4nuLXwjcXPiNrYqpkmA+zwOq /Nk4HmsW5wAFAyOciuP8I/DTxD8Z5ZdYvbtNP0aEhJ9Xv2KwRgcBIx1dsDARQTx0r7zJ+Cpz pfXc2n7GitddJP8Ayv56voj84z3j+EK39n5LD29d6aaxXzW9vLRdWQaz8S7rUydK8OWtxYwX f7o+WDJf3ueqsyjIU/3EwPXd1rotD+B+neAo1uvG8rm9UbovD9nIBcHjj7RKMiFf9lcv06da 27HxLo3wvs5LPwXayx3cgMc+u3ag3s47iIdIVPt83uOlP+GXwc8QfGLVmTTbdmiVv395OSsM We5bufYZNdGZcZ0sPSeByKHsqfWX2n5rt6vX0ObKeAq2KrrMeI6ntanSF/dj5Po/RWj6mZ4h 8X3nisW9lFDDZ6dbtiz02zj2W8GePlUcsx7s2WPcmseaJ7eV45EaOSMlWVhgqR1BHY19rfBv 9mzQfhFGlyqf2lrGPmvZ0GUOORGvRB78tyeccV5F+2h8FhoWrDxZp0RFpqEgS/VekUx6SY7B 8c/7X+9X57OcpScpO7fU/ToQjCKhBWS2S2R3/wCxh+0TqmpeENS0GDW7rRfEFvpstlDqMVul 1LFAyFYrlYnDJLLbuwcIykMBtPDtVXVviB8bPj1r41/w/HpGpeNPD9rJ4R8ReCxp1/c6CNdi hlDz3axajaQy6bqdpc2k8Nxdx3Iht0XZGZjtPzJ4K8YXvgHxTZavp8hjurKQOvo47qfVWGQf Y1+m/wCxz8Z9I+JPhRLRo7drfXIS0PmBS7EKRJayHGWKjdtzn5QwGFVRUFnmvws/Zj8Kfsvf E7xRrcWo3ni7xLqEF3pcN3JAlpDHaz3BuCLpUZlv51byoxJMoWOO2jjiSIeZ5nU6jrcV1Hep a6XpGkrqt++q6h9gtRCdRvGRY2uZjyZJfLRE3E52oq9FAFz4heCJfh94pmsGDvaP+9s5WJJk iJ6EnqyH5Tzk/K3G4CsSmB4t+2b4B17xZ4VsbrSJb67trWUJc6dACwk3HCyhQMsQeD1wDnjB NfJ88ElrO8UqPHLGxV0YEMpBwQQehBr9Ga+PP2y/DkWhfGKWeDT3s4tRgS4aXdmO6k5DOAB8 pyMEckn5v4qAPJqKfFA8wJAwq/eY8Kv1P4fjUnnLaupgZw64PmHgg/7Ppg9+vGeOlAH1l+yT 8Xj468IHw/qsivqulRYUSHL3Nt0BIPUrkKc9QVPOc1zEP7JGtaB8c01HQb2HS9FtplvILk/O 8OScwBM5bHI5wCrDk8ivBPAfjW9+Hni2x1iwYLc2Um4A/dkUjDIfYgkfjX3d4D8a2XxD8JWO sWDFra9j3AH70bA4ZD7ggj8KALttoVlZarc30Npbx3t6FE86xgSShRhQzdSABirVFFAFzw/r Mnh7XLS+iBMlpKsoG4ruweVJHYjg+xrzD9p7w9ZfAzUPDfinRrHw9ovhG/8AECeLJrm6vhYW Q15T/wAhDxHr927PFaRNMkUVtArTTkLEG8gPEvodLqHhaw+I3hu58Oarf3GlwXM0F9p+oxDc +jalbSrPaXqqeHMc0aEo3yOpKvlSQQCv4c8T6X4m8D6a1trg8Q6zZyTW+sXa6BJoMYmYrNGs dk6hooPJlQwszSGWIK3mSkM58X/a7+A1x48tbbXtEtHuNWtttvcQxLl7mMn5W92Un/vk/wCz Vn4ZfDrU/wBkr4jaV4Jii0m6i8RazDDJoc0y6h4p8QWXnfZpPErvbuLPRNJsonlkgsoolgEW 6LMc0qw16x4jstQvtAvra0mbStTkhZYZXRZPIkK5R8cqynIYEZDKQQSCDQB+fV1az6Fq0kFx CI7mymKSRSKG2urYKkHg8jBFfXv7Mfx6i+LOn3mny2Nrpl7pYVo4LZCsLQHABUdiG4I4HIx3 x5P4L/ZE8VfEfUr7UfE13JpTyPJl5/31xcycjdjPCZ7k8joMEGsL4I+PtS/Z5+Lk+manDMtt NMLLUbZQWIIOEkUD7xBORjOVY46igD7LooooAKKKoat4o03Qr2ytr2+tra41GTybaKSQK87+ ijqf/rj1FAF+iiigAooooA8U/bF+NN18LrrwJpR8VWvw80bxdq81nqniy5FuF0mOK0mnSKNr lWt0nneNURpkddokAVnK48l/Z3/b++LHhm0+GlnBrVnq+uftA6Lq8Ogag+kpDZad5GqoLXV5 kAGEh0u6W5eNyFcwsmdzrj6V+LHwP0f4xnTn1O78RWE+measM2j61daZKUlULLG7QSJvVgF4 bJUqCpUjNclrPwm8Lfs7G38WaN4b1XVLjRtIg8MaTp0N1JJa6LYARJ5NtCxKQo/kW4copZzF HnIXgA8t+Mfxf+I9/wCOrTxWvxPudI8IeLY/HOuyQWGi6e76doehXsVnb3scr27r9puWkhl3 urQ7JpB5TPiQfK/xx1j4ka9pWm+NJtbgsb20vfCPhnX7O0sLfy7/AF27s7G81SRwyMUiMF7k JGUKvCx3cla/a34JeJLX4pfDibwtrAnM0NsoQSnbO9vxsbJyRJE21SecEIxOWxXkvj7wEsia p4a12GOcbTBcKBhZUIysi+gYYYd1PHVTgA/EHQv2rtc13xncXln4ktRotzoer6u8d7BbvFpE cDwx2zSQWwe4iZXnj80SysxCu3lxYKr3v7Ov7dviH4eWSW+s6tH4h07RbzUtf1KGWzs79N+m aM86taT26iOSNru40/EixJKhzG3zdPor4o/DW6+E3ja90a5UHyn8yKULtFxGxysn1I6+hBHa qHgrwJqXjbVYtM0TT5bu4fpHEoCoM/eY9FHucCgDt7n9sHxr441rTPDPg/xtouqX0qeEPDUm t2Nnb3tpca1dSXN5rEsRUeXKItNs2bYjbFMxPBjIrxe+8SfGD4pfHDwVaah4w1rxroXie48U tpNpLp9nEZdN0zUjZQXUn2eKNfPk8y3k8xAkbRyD5MgtX6YfAL4XeLNX8EafpkqW2o3+mxrb XF4rGO1iIHyqzkZZgu3O1SehIG4GvTNJ/Zn1+88wX2paPp20/IYFkvN499wi2n/vqgD5F+C3 7GFloBh1HxWYtRvBhlsF5t4j/tn/AJaH2+71+9Xt93ALSCKSCPAtRhY0GMpjBUAe3IHqBXsV p+y6vAutemcD/n3tFiP/AI8z1Je/ArwV4LgabxBrV21tcsI4jqGppZIrEdFaIREk+hJ9sUmg PJ/CfhvUfE199i061a8v5P3koU7Y4c9C7nhVAGB3O04BPFetaD8NvD3wbsIta8TXsF3qCMDC WUtHDIOdsEXLO4/vYLcEgIMim6t8ZfD3w+0YaZ4RtrW7dOkkQJtVOAN7SdZmPGSCSxBywNeT XviSXxnfyalc3/8Aadw7NH528OseGwY1A4QAjG0Y5HOTk0JAbfxX+Ji+PdWj1GaBNNsdOhdI vOdQ4ViCzyMDtHCrwCQvzcnPHzD8Z/207fSXm07wksd3cLlW1CRcwof+ma/xn3PHswql+2Zo 3jDVPEumWtnJeXuhaliO3s7WM8TgfMrhfvEgbgTwAGwBgk/PviLw9e+E9budN1G3e1vbR9ks TYJQ4z1HBGMHI4INMD6e/ZD+PVx45t7nQNbu5LnVoC1xbzSnLXEROWUnuyk8D+6fRTXteo6j b6RYy3V3PDa20Cl5JZXCJGo7kngD61+e/hnxHeeEfEFnqdhKYbyxlEsTYyAR2I7g9CO4NfcP gzx3pPxk+Fh1JofOsby3eK9teXaNtuJIiByeOnQkEHvSbtqxSkkm2eW/Fj9t210mdrPwnbxa hLGwD3lyjCA+oRQQzemTgegPWivObb4Q6PpusXcgee+tTK4t1m+TbHn5dwHVgOpzjnpRXwGL 8S8moVXTi5Tt1ilb5Xav62t2Z8fiOOMtpTcI80vNJW/Fr8j7iHiOe8B8Za3EJNU1ZVfTbSTJ WBMZXI7IgIwONxJbqSa4Dxf48js7qWa7le6vpjuK5yxPuew/zisv4kfE7VdZvxJKBDLcxK/m L0CkfdQfwgcj1/nXK6NoF34iuW8pSVz88rn5R9T3NfyznmIWazdfEVGsOm5av3qknvUnbRN7 RivgjaCtZt/07lOTxo01VrWWnTouiXl36t6s3fDvj24vddWO6CiG4IRFQYEbdvc5r2T4W6vp viLS77wN4jQzaD4j/dQjdtNtcE5BVv4CzBWVhgrIqkfM2a828P8AhO10BQyL5s5HMrDn8B2F acsYmjKtuAb0JBHuCOQfcV5PD3GayDPaWaZZFqMbKSWnPG+q8ns039pJswzvBUMbSdFK3Z+f f/PyPYfgZ4r1HQtV1HwH4kcNrnh0j7NcbBGmpWjZ8qZAOACqkbRgKySIARGWNn43+Fb/AE+6 0/xx4eill8QeFlYyW0Wd2q2ROZrYgA7mwCyDGdwIGN5I5/WPtfxj8DWXiLRRG3xD8CDeq4Cv qkJGXhOMfLMEyucASx4Pybg3o3w18f2XxO8GWOs2Dq0V1GC6choXwNyMGAYEejAHBBwM1/YW KxNJOjxFlLTo1knpsm1rF9lJXstGnzLRxPyWVKUJSw9VWlEgn1fTfif4GsvFmjImp2N7Zlbi FRvN7asDviwOGdCWKjnJ3KOHzVzw7KPFfh+XSLi7M13ZrHPZ32d7TxH5oLjOcMwxtbsxVuAr gV554dkj/Zl+MTWAVLbwN45uWltsLti0rUiC0kfHCpKAXGeAQ4yqooPca9plz4I1qKfT7S6u 43laWzjt4S5RnIM1sxHCRyffVmIRXX5iAqKfpZ8knHGYdc0KiSkutnpdrvF3UvK9rpI51/K9 0fnJ/wAFA/h/pHg349XsmloLO7voUu9V04RMi2Vy5YM0ZIAeKTAcMuRl+cZArwmv19/aD+B3 h34h6Zf3er6ZbXEN/YnTNQnES/aIYC6sk6OeV8lwHPIBUEndsVa/Kv40fCTVPgb8StU8M6ug +1adJhJVUhLmM8pKuf4WXB9jkHkGtsJJ05PDTe2sX3j/AJrZ/J9TbEOk+WVJNaK99dettFo9 0um12ctRRRXecxc8PeIL3wprtnqenXMtnf6fMtxbzxnDxOpyrD6EV+q/7M3x1039qj4LQaky xx36r9l1W1RyGtrgAfMuOVDcOjDkeuVNfk5Xrv7GH7Sk37Nnxdgvp2d/D+q7bTVohk4jJ4mA HVoycjjJBZeN2R4meZb9ao81P446r/L/AC8zWlOz1P081bQl+J3g+90PUZFj1Wx2lbgKMh8H yrgKMfK2GDAYGRIgJAyfA/E/wAu/jD4e1bw7qNotpGm6G5nlOI7OVRuDBsckHBBA5DA/dOa9 S+NP7QPhD4KeHNN8V6t4gsbOJgrWuyQSNqVvJtLKirkspG1gwwAQuWAJz8L/APBTX/gojo/x ZiHh34Y6lqstrydYvLdmjtNRQDCgrwSF55OAwK5B2rj1+FsvzPPaCjgoe+naUpJ8q7u/p079 DwuIOIMBk9P2uNna+yWsn6L9dvM43Tm+F/7P+uR/8JlrKeJ9YjlZRZ6YguLSAjOCzEhZCSAO DtGecjms/wCJX7RfjD9pTVo/Dnh6xu9P0e8byYNKsAz3F6OABKygEjH8Iwo9B1PzLoHhDUfG V0biRnWJjlp5cnd9PX+Vfpf/AMEp7rwfrehajoslhZW/inT1EkrbMyarBwPMZmyTtYkGNdqf MpKseV/ScfWyThOi69VfWcTHovhi/wAbW87v0PzSCz3i2VlfDYR/+BSX4Xv8o+p518Mv2Q/A XwH8FWfi74za4yT6jMbbQvC2mW0t5f65dBQwht4IgZb1+QdkCsuNxZgoYjjv2gPDXijW/hT4 U8Va54bvfBd5ZKvh3X/DTwR28GhapFCkgaKOJ5IliurdorhVjkk2b2RnLIQP0L/aQt9W8LfD zW/GPgzw/pWo/EDSdMa0sL1tIF9fW9q88ZnMSpiaby4w8y2yMPOeNUA3MK+OPjNd337Rvh29 0Cb4geJPEuo6bjVvB0XjXS4fDviDxVHHbynVBa6ZHbWsktvDstjFM9qrF3nQO6lGPwmI4rxW exWKxEv+3doxfVJfruz9IyXhrA5PS9jg4W7yesper/TZdEef/su/s7aX8VoJdX1W/Wa1spvK bT4SVkY4BBduyntt64PIwRX1Xo+jWnh/TYbOxtoLS0gXbHFEgREHsBXxJ+z/APF2X4P+Pob1 2dtMugIL6NRktGT94D+8p5H4jvX3BZ3kWoWkVxBIk0E6CSN1OVdSMgg+hFcp7ZJXD/E74oeE LO7i8K63cx3M+uMLN7WMeYYw+AGfH3OSCCee46ZHcVzelfCPw9o3jW+8RQabCNXv23PM3zbD gAlAeFJ6kjkknmgD4t+LnwzvPhP43u9Iug7RofMtpiMC4iJO1x/I+hBFdx+yL8a5Php42j02 4unttP1OZGimyP8AQ7oEeXKM8dQAe3TPAr1H9ti08OX3giFr++gttftG8ywjUbpZ1JAZCByE I5ycAFRz1B+UKAP2Dvoov2gvhStxAsEOuWBOF/hhuVUbo89RHICME9mVsZXFeMDILKysjoxR 0YYZGBwVI7EEEEdiKxP+Cdfxa8Ra/p2nJc2Go3LviyuXMZ23NuP9Xc5PQoSQWJw3zfeYgD2T 9ob4ejR9QHiCzjP2a9kWK9RV4ilIws3sGwFP+1tODuY0gPNq5b4s/CbSvi34caz1GAtNArta TKcPbyFSNw5AI6cHg4HoDWx4q8X6Z4I0eS/1a9gsLSLrJIcZPoAOWPsATV61uY722jmhkSWG ZQ6OpyrqRkEHuCKYH536qk9rey208bQPau0ZiK7TEwOCCOxyMHPPFVq+s/2lf2bdK8T6HrPi SwX7LriItw+ZAkMwQHeCDwGZe/cqOmST8mUAFez/ALHfxkfwX4wXw9eOzaZrcoWLuLe4PCt9 G4U++09Aa4b4W/BTXfi1duNOtjHZQf6+8lBEUfqB/ebH8IyfoOa+sfg9+z14e+EtpHPaxLqG qMvz6hMoLnI/gHIRfpzjqTSuB3tFFFMAooooAzfjR8L7349+CNEh03w94M8Yaz4d1a2urnw3 4kuBYab4utI4Z4oYbudYpWaOzknN2qPFKpMIATcVdfMP2K/iT4fsx4i8GaVquu6wmtWY8Q6f qKxSaf4aS0ltoNdW00vSSfMsbRYtWCxTTK0kjW80UjoI4Ur2vRNZuPD+rW97auEntnDoSMj6 H2I4r5z+MurwfBr4yeOdA0nwN4+8F2Ytbm5t5vDPiK58P6NDcRFja6xqmrSSRRWukJA6GG2h kkt43N5E9vLIEQAH0FWOfAGjN4xbxA2nWzaw0KwfaWXLKozjGeAecbhzjAzgYq18OvHel/FC 4i06DUpte8S2ujpe65faVpF1DoyXAhLPcRyTqm6yunjma1uIg8MuyQIxCHF6gApJJFhjZ3ZU RBkknAA9aHcRqWYhVUZJPAFeFfHj9r3S9Gs7vRvD0dtrN1MjQz3DjfaRgjBA/wCehxn/AGee p5FAC/Gn9syx8NGXTvCwh1O/XKveOM20J/2f+eh9/u9PvdK8a8D+A/Gv7QXi86nFNdzzRyBp NUuXKx25ByAp9QeioOPQCuX+HU+j23jfTH1+CS40cTqLpFYqdh4ycckDqQOSBivvjRLGy0zS LaDToraCxjjHkJAoEQTqNuOMHrxQBT8Bvq7+D9POvRQw6wsQW6WJw6FxxuBHHIAOBwCcVrVD qOo2+kWE11dTRW9tboZJZZGCpGoGSST0AFGn6hBq1hDdWs0dxbXKCSKWNgySKRkMCOoIoAmo oooAKKKKALGj6zdeGdatNTsSBd2L+Yik4WUYw0bf7LDIPpweoFerfF3w3bfEzwVZ+KtHVpbi 1h3uoX55rfJLxkD+ONtxA5IIdQMtXkNd7+z/AOPf+EZ8THR7hiLHWXzExPyw3GOAc9BIBt/3 woAy5oA8I+MXwH0v46tpMUzXKX0Ev7hrOPzZ7mMjLRqBnI6HODtwT0zXtXwR/Y403wBoCi9g g0XTUHmyWkEh86XA5aefOQcdQpOMcOBxXofiW88O/s/6a1zYaMBe6rIyRrECDKwy2xpWzsjX khBnAztQ4IrxL4x/FzUdY0K+1XWTcXNhpsTXP9m2S/ugFGc7Sf3jADOXOARkBelAHpPi34+6 b4d0b+y/CENtHbWyFPtojCWtso6mJSMOep3H5OQcvytfP8/7aUHjb4jWXhhvFmt38kuY1ure YWduZR0jzAI/MLc8nK5wBnPHy58Zf2mNd+LbSWoY6XoxPFnCxJkHYyNwW+nA9u9edQTyWs6S xO8csbBkdSQykHIII6EGgD9F7uFdQz9pDXRPecmUn8WzUEVhbaTFJJb2kUZVD8sMaqzAdhjF cR+zj8YU+LngGKWd0/tfT8QXqDqzY+WTHowGfqGHavQKAPkT44ftY6147muNM0pbjQ9KBaKR c7bmcdCHI+6OxUe4JNXf2OPjUPCHiM+G9Rm26bq0mbZmPEFwcAD6PgD649Sas/tnfBc+Htc/ 4SrT4gLLUpNt6ijAhnP8f0fv/tZ/vV4SjtGwZSVZTkEcEUAfo3XhX7Z3wY/4STQh4p0+EG90 uPbeqo5mgH8f1Tn/AICT/dFdZ+zL8Z1+LXgdEu5Q2taWFivAcAyj+GX/AIEBz7g9sV6PLEk8 TxyIrxuCrKwyGB6gjuKAPzlr6C/YftPE9hrd1LFZSHwxeofPmmYoglUfK0YP3mPQ44x1OQAe 48LfsX+G9E8Y3Wp3jy6jaeeZLSwdQIYlPIV+74OQBwCAMg810fxW/aA8OfBewFtIyXOoRoFh 061wGUYwu7tGvAHPOOgNAHHfGTwT/wAIr4iNxCoFlqBMiADAjb+Jfpzkexx2oqz8G/jRZ/tK WWp6Nrdvb2d9DKLm2jhYgmIYGQWySwOQT3DdBzRX4txH4a4qvj518ucVCetm2rN7pWT06rte 3Q/Ls54KxE8XKpgkuSWtm7Wb3Xp2+7oLNcXWuXaKxknlI2ooycAdgK1PBPiE6HqRt52ZbeY4 YHgRt6/0P/1q6/QdBtNFtl+zplnHMjcu/wD9b2rm/iH4c8iX7fCvySHEwA4Vv734/wA/rX8z 082wuNm8A4csGrJ+fp08v+Cf2pHE06r9jayex2dZfiDxba6ApVj51x2iU8j6ntXJN48vhpEd qjBHQbWl6uw7D2OO/Wqui+HbvxFOTEp2Z+eVz8o/xNcOG4bjSvVx0koLz3+fS/bf0MqeBUby rPRHrfwz+IMnhjXrDW7FmeIfJNH086FiN6EeowCP9pR2yD32pSwfBL4nW/inTZUb4efECRGv mDbYtM1CQ/JcYI+SOckBumJCScs6geR+H9Cj8PWPkRu8hY7mZj1P07V6X8I/F2lXWg6r4O8T tH/wj2sQS7Xmk8uOAsCZELfwBhlw2RtcMc5YV+yeCvGuHpYirwtjZN4etf2bf2Zb2Xa/xR29 5Wt77R8BxXlal/tlDeO/mu/6Py9DT/bO8X2mh/sq/EnWbjS7rUrHwroV5q7gMLfz5bOJ7jy4 ZWDeXKGhG2Xy3VGxwzArXi3wg/4Kd6vbfBKxXxvP+z34G8dWmnRK+g+JvjFDZ6mkoiUg3cP2 JjbSPwxjZmZd2GKnIGl+0t+0VYfAj9kb4naLr+s2cdz4e8O3qafazW5D+Jo/s9wLaWEbcLFK YgkhRNqukjKVRo2bwr4n6t+zl+2f+1X+z18atFtPgrP8PreLxFe/E6TXJNGsrmKWfTo0sU1O 2uGWW4kS4VwpKSBCN4IUq5/sDhTKMJRw1TD1IucVJvn1tzKCkkndL94kkurdlufnWJqyck0/ l8/0PpH9gv8A4KC3v7Rl74i0fx/pOn+CfFuneIZNBGiHWIdQMjC0huY54JEijElvNHKxQjeM Rg+YwmQDxP8A4KveC9b8NfEjw7NdNZTeHms3g0l44gtxEqsGeGVs5faWG09Np7tvJ+cPiN+1 V4c/aO/aT8b+NfhwfsHhzS9at9P0S7tojamVbOxtIlnRQAUXch2DAIRU4B4H014R8V/DL4z/ AAI1TVPGV14g8ZfFzxQZNPhtgpub+3mB3xC0iUBIoOhJ443r/s1x5lhI08U06fK1snduN0rq 7u/vd+j2LpyvHe58h0VsePPAOsfDDxZeaFr9hNpmq2DBZ7eQgshIDDkEggggggkHNYd3eRWF u0s8iRRoMlmOAKwhCUmoxV2xznGEXKbslu2SVkeJfGll4ZjIlfzZz92JDlj9fSuX8V/FZ590 Gmgxp0MxHzH6Dt9azfDXw/vfE8ouLhngt3OTI/LyfQH+Zr9CyzgynQorHZ7P2VP+X7T8vL0W vofmGb8e1cTXeXcOU/bVXvL7MfNdH6u0fUPEnjbXPiZewQzz3V0kEaw28G9nWGNfuqM9APyF fR/7BHwZTxd4tGgjRNI1zxRdZksBqtyI9Ls0CkySTRr89w69VjHHcggGvNND8O2nh628u1iC Z+8x5Zvqa3PDHifUPBfiCz1bSbyew1KwkE1vcQtteJx0INYZxxrJ0vqOUQ9jRWmmkn921/vf VnRkfAEY1v7Qzuft67111ivk97eei6Lqeg/tZ/s03f7LnxNj0Ge/tdTgurSO7guIYxCGByGU xgnZhw2B/d2mqH7LsPjNvjdok/gO0nvfEFnL56RoQsZiHEglYkBYip2sSR97HUivpC4+H/w+ /aE/Zug0/wAEaD4h8WfEvW1jv73UpWM91Y3S/K5vLuQqiow3gRqcsNrBc4NfMnwP+J+ofs8/ GvSdeWOeOfRrsx3ttja8kWSk0RB7lSw56Ng9q/O8UpSpSUUm2no9n6n6VFJNH696fNM1rBJN GsFwUVpI1fesbY5UNgZAPGcDPpXxz+2L4O1fwB8WNP0f4f8Agg6XfeNtf0vXW8ZQaANfv59Q NxeLcmS6u4p4bRLNDZTIZ9qi3a4jtzGYxt+vtA1208UaHZalYTpc2OoQJc28qHKyxuoZWHsQ Qayvit8MtG+Mnw91Hw5r+jaX4g0y+Cu2n6mGexupI2DxpOg/1kJdV3IwKsuQQRwfz/h/MXhs R7Ko7Rlp6Po/0+eux1VYXV0flz+0V4Q0++urfxz4XufDGq+FfETiCa68NXqXmk2WrRxp9us4 pEOAiTbynQFCNuQpx6Z+xX8Z/wC0bE+ENRmJuLZTJpzNyXj5Lx59V6gemeyiqHiH4oQ3Ovat 4a8V+H5PE/ijx74vXw+J7xItEs7+70y5bTo7fw9ptvOztDCXmSSS+uY544ZorxkntU2J5h8Y /Cqfs/8A7QGsaXoWozTr4dv/APRLhyDLHgBgjkAKzoTsYgBWKsQMEV+jnIfbWoahBpVlLc3U 0VvbwKXklkYKiAdyTwBXz98Z/wBtWO183TvCCrNJ919SlX5F/wCuaHr/ALzcex615T44+LHi 79onxHa6asc9y11KI7TSrCNmV3PTCjLO3uc98YFdtpP7L/hn4daToGs/EPxHeXek+Ibi8soo vBlu2uTQT2qy+fETbpM0txC8T77eCORgsM7llEL0gOF8D/Bvxx+0Le3OoaZZyavNJdLbPc3d 9Dbi4uHVmWFHndBJJtVjsQlgozjFeyfs4fs7+AtB+Kth4d+IMviWbXrzUf7G86DSnTQtH1I2 8V1FYXF1KuxrqWCUMihTHuIQkyMiG/4V8G6f8UN+l+EPDEWveF/Aeu2WuW+keGdbkt9c8eeE 9T0txHq0OoPPBHIk16ltIbdGgCHSZY98m5Ffkvid8IdMl+GEvhXxF8U9Q8K694n1WS+8S6Zq etyX82nLa3TroWoTtZ285n1qys7fTVcJexJJNZQyStOVy7A+8tS+Lng34OfD8zeFxpd5ZLLd W73cE6NaRTWsrQXAnnBOXiljeNlyWVkKnZjif4PfFNfilaXuia69revfQtLA8ahIruBh8yDB 6rng5yVYckqzV+c/7Y37TNz8ePjdrmp6Rqeqp4alRLKyt3kaNGgULuJTsHkDPg88jPTA6T9l L9qXWLLx5Z6drOqEs/lrpl3IBm1nRdqKcYyrrlTnlicE/MaQHon7ef7OV41pNNCZZ9R8No0s RJz9usm53gdN64OcAcq45+WuS/Y6+OVvP4Ym8OaxeRW8ulIZbSadwimDPKFj3QnjP8JA/hr7 j8WaZB8e/hhb6rp8KLrFiGKQswysmB5tuSccNgYJwCRG3Tr+fvxF/Y51LWPim39grDbaDqOb hpZflFic/NHs+8SD0GPY4wTTA+lNa0a18RaRc2F7ClxaXcZiljYZDKRgivCvAX7DdlpviS4u devjf6fDOfstrFlTNHn5TK3BBx1Vfz7V7b4P0CTwt4XsNNkvJ9QexhWE3E2PMlwMZOPb8fUk 81xPxo/aY0P4SRyWqMup60B8tpE2BEfWRv4fpyfbvQB6DpmmW2jWENpZ28Nra26hI4okCJGP QAcAVHb/APEvuhAQRDLlouOFPUp/Ue2fSvK/2Y/2jZfi299purm3h1iFmnhEa7EmhJ+6B6oe PUgg84Jr1u7thd27RklSeQw6qRyD+BpNDRJRUNlctOhSQKs8XEijpn1Hseo/LqDU1CYgooop gFXL2PT/AB74UvvC3iqTUrzw3qkSRMkNyyPYyRypNDcRdQJIpY0deCMryCODTooA8g0L4eeI /wBhXxwUN9ZeJdT8b6xb2N1aalifxB8S42mlkmXS7KxcWuh6ZayXt1eEiN97+Y1wYQ5lf2zx Fpi6RrVzBEZHtlkb7PI4x58W4hJAehVgAQRwQcjiuB/aU8F+NfiV4Y8PWXhTwDY/EjSo4lt9 Z0Nbqz099VKXyzJZ6hcTyK40uSOR2cRLMfMgAaCZHZG4/wDZj+K2mW2v6t8NodJvrPULvxXd /wBlxaVpNtpvhLT5GiuQ+naUjSJdyWxm0y+/0yS3SCW5iuCBCJUFAHafHHwBc/Ez4a6jpNnd S2t3KoeErIUSVl58t8dUbpg8Zwe1fL0v7J3iqy+Hd7r93AltJaJ5osD81w8Y+8xA4Ugc7epG eh4P2jc28tjeTW1xFJb3Nu2yWKQbXjPoR+oPQjBGQQaxvHHjPTvh/wCGLrVtVkeKxtQN5VC5 JJCgYHqSB6c0AfnzX0v+yn+0Xp9h4IuNF8RX8NkNEi8y2nmbAkhzjYO5ZSQAByQQAOK+ffG2 oabq3i3ULrR7SWw0y4mZ7e3kILRKf4eOAM5wOcDAycZpPCHgvVPHutR6dpFlNfXcnOxBwo/v MTwq+5IFAHrfxv8A2xL7xnDc6V4djfTtKmVopbiRR9ouVIIIHZFIPb5vcdK9C/Yq1DxG3gaa 01OxuE0aLEmm3UvylgxJZADyVzyDjHJGegB8Fv2O9M8HLFqHiMQ6vqYwywY3WsB+h++fc8e3 evakURqFUBVUYAAwBQAtFFFABRRRQAUkiCVCrAkH3waWigD2XwTq1v8AHL4cXOi6rIP7VsVV HmKgvuA/d3Kj1JBBHAyGGNpGfINU0q50XUrmwvohFdWjmKZOq565HqrAhh6hh06V1/wn8J65 b6vDr1hGsUdsrACUlRfRkZaIezYXDH5QwU/NtIrqfjj4Oh8YeG4fFOlgvNZwn7QoTDzQAkkE dQ8Z3HHX764JxjCniaU5ypwkm47rsNLS5+an7UfwXb4VeNzc2cZGjauzS22BxA+ctF+Gcj2P sa8wr76+KPw7svit4Iu9HuyFWdd8Mo5MMo+64+h6+oJHevhPxL4du/COv3emX8Rhu7KUxSqf Udx6gjkHuCK3EdB8FPinc/CLx5a6nEXe0c+VeQr/AMtoSRuAH94dR7j0zX2z4I8Vx+OPCtlq 8NvcWsF/H5sSTbd+wn5WO0kcjB696/Pivq/9ia98RHwPcWupWc66JGRJptxL8pOSd6KDyUzy D0ySOewB694p8M2fjLw7eaVqEQms76IxSr3we49CDgg9iAa+E/id8Or34Y+ObzRLpWkeB8wu BxPG33HH1HbscjtX33WffeFNM1PXbTU7mxtp9QsVZLed0DPEGIJwfqOvbnHU5APAf2TvgD4m 8MeI4PEl/M+jWrRMn2N0zNdo3Z1P3FyAwzzlRwOtfR1FFABXiH7S37M1h4g8Palr2h2hj11Z WvbhVckXS7fnAXoG43DHU7uuRj2+igD879B1+98MapHe6fcy2l3DkJLGcMuQQf0Jor7h8KfA vwx4N8U32s2Wmx/2hfSNJvkwwt933ljXogPPTnkjOOKKANi3tJNPt47eZSksKhGBHcD+XcEc EcjIrD8W+LrOyt5bXYl3K4KsmflT6n19hzx2r13xlpGnfFf4Vaf4w0G4N7ZXFu26RAVaW3DM qufRkAwc8gA5+7ivBYfh3eS6pJCSqQRt/rm/jHsPXH4e9fwJmXC1DKsxnDFztBe9B7cyv3XW L0aWuz2Z+05LiaeIg5VvdlDSS2s1+Py/yMAHBzgcV6X4W1OHVdFikhjSIJ8jRqMBGHUD+f41 xfi7wufDtzGYy728o+Vm6hh1B/n/APqpvg/xAdB1QFyRbzfLJ149G/D+Wa0zbDRzHBqth3dr Vefdev6nvYimq9JSgejV1vwLvPK+J1gilT5oljbnkfumb+grx/xH8Q3n3Q2G6NOQZiMM309P r1+lQ/DL4gXPw+8YW2pROTskDPu5z1Bz9QSD7E98VzcMZTWwmLpZhX0UJJ23duv4bLfpoeNj sqq1sJUit2tEfH//AAV8+NOrfBP9v3XfB8c41/VvEOnaRfeGVvpZBHavfTX0Tx3MzHalvE1s CiLh3LhFDM3Hi2pftN23gfUdR07V45dY1O11SLSYYtNtorQTy/2fBdyYNzcBD/rGIXeHxhAr lSx/YT49fsHfD39tPwd8Qr/Vn1Cd/it4d0vR5WMibNMbTZb6W0ng2qHSZJb6bc28/cTbtIJb 8mPih+xRL8P/ABPr/hrX9a8RR6q9/G+qm6SyukvJo7OG0Bkie3MMiyJFHKDs+/8AMuFbaf7r 4bzSnmGDjQg7ygk1trG13bvrqvn1aPxWvTdOburf5mFYftKyQeJvFNrN4W19rLSDpxsxHFGt xcveRGUrIskiiDaepmKKvIJBwD7z+wr+2k/gLXLL4geGrM3NvJ9q027sbxkDN5czQyxl4y65 WWLIeNmU7QQSp5+dfEf7H3hmw0WKNdd1rTtPsodNiggkFtcw77GB7eF3WWJvNJjbDK2RlVZQ rAMI/BAj+F/gtvD2iXN9JaNd3V5JcXPl+dJJcTvNJjy0RVUu7EAKMA47V99lHDuNzlqdCNra Sk9vJ+b72u72b3Pk+IeK8vyWnfEyvJ7RWsn/AJLzenY+6v2+vF+kaj4QsPGHiHx1pXiT4jau kLw6Ro0IXT9OsSpZYi+NxkBcHLnd94Y4Br4qutQ1Xx/qQQB5Tn5Y14jjHr/9c16f+yp8MNE8 UeNo28atrUVgE3Wltp1qbq/1CUsNtvEpOFZyeGP8zXsP7Rf7Jut/Ae1s/EMnhNfCnh7xHO4s 7AXZu5rAgDbHO+P9Ywy2P94cYIH1U8fk/DkXTwSVfE9ZPaL8v8lr3Z8JDLc84qkquYN4fC7q C+KS8+/rLTqongHhT4Y22kbJ7zbc3I5CkfIh+nc11IAAAAAAoor89zPNsVmFZ1sXNyf4LyS2 R+n5RkuDyygsPgqaiuvd+be7YUUUV5x6h7z+w9+0P4w+HPiiTwX4b1XRtKTxncxQJdapE8sO nz/dEqKvV2GFw3yk7M8DNP8A2+vgBZ/BH4i2TR+LF8UazrEDXWs+aUW5iuS2WkaNBiON9w2g nPB6jBrwWGZ7eVJI3aOSMhlZTgqR0IPY1+gn/BP+x8E/tCfs9614bvfCsj6neB4PEupyEu98 xbdFJ57EuZCfmCjhTGzcZUMAH/BK/wCPJ8ZfDa88E382/UPDJ86y3H5pLN25Hv5chIyT0kQD pX1dX5xeEPhR4o/ZW+PWseMfCVnrPiPwT4F1iTS9Vv0t1R5IVUG6Ro85ZY1zmQDYGRW+Xiv0 T0XW7TxHpNtf2FxFd2V2glhmibckinoQa/OeJMB7DE+1ivdnr8+v+Z10Z3Vj5Y/4KE/s8avH f6l8Rfh74a0+DxFrGiT6X4m17T7210fWY4opLWa1kk1GaWKS309I4LuK4FtKJttwjIkhjwPB fi18Kx8btH0a48N3viTW9f0TTIxc3PiTSL3R77XNLa6litL8G9AkuFji8iCSVmaVsRvIF8xC /wBsftUfATS/2q/AyeDp7qGK+trtb+Jp7AajYx/uZYZIr23LxiWCaCeaJo96ORJvRlZA689+ z3+z9ov7L9zdeIfG+teK/GfjzTrRfD1t4t8UXkFze6vZCOC4aOwgici3t/OO1lZRM7W2+V5Q Emb7HJcTUrYOE6m+33f8A56kUpWR4l8M/wDgllrniL4I+K7K71+58N634n0hrS3ukEiCFxJH NGjorJI1u8kSJOjMpmhaWIqofdU2k+CL/wCKf7Eem6P4+uLLwp4qudTeK00O28HWsGh+DF06 4ihuNHtrbzYpbrTp1jMLyC5xdw3DEGOKQQj3L4gfGnVvHJe3gMmk6W3Hkxviecf9NHB4H+wv HJBLA18dft+eL577WvDOiNczPBptm8qQlyUiV2CqoHQAeWcAV6pB9SeIv2Xk+DH7G9xp3wrt 4fEF1Np159omugXudShvnM92LfH/AB7xvKzyi1gEcSlsIq4Cn8/tU+DHiTQ/ASeJLzTZbbS3 kWMGTiTDZw5TqFJ4ycZJHrX1v/wTp/a+uNP0RvDWrzTXcOnDcY+XkWEnHnRjqSpIDp3BVhlt wb3v4/fA3TfFHhi81fTIobvR9WgL39rENyTJIMm4iK9Mg7mxwfvggg7kB+UlKjtG4ZSVZTkE cEGvdPhv+wV4s+LPxKvdM0byZPD1nPtbWmYG3MZwRgj7zgEAqMkHPUCvpvxJ+xJ4K+AeiaFb wRW+s3s0u+Zr6FHnaREP75eOIwSBtOQGdSKYEH7D3x51SDwzp+oa/b3lpbXYW0vZJl2pPgAR 3oz25w54GNx5CqK9S+P3w8/4RnXDrdpGF0/U5MXKqMCC4J+97LJ+Hz+pkFeerNHOZEVkcxnY 6gg7TgHB9Dgg49CK9a+Cvia08ceEbrwdrAEzQ25SDe3zT23QAHrvjOBnrjYck5IAPgz9ov8A aq1pdZ1Hw5o9vc6GlrIYJ7hztupMf3cfcU9QQSSMHIzivAHdpHLMSzMcknkk19Wft5fs53el 3Vzq0cfmaloiBL1lXaL21P8Aq7gAdxyG9MMOic/KVAGl4Q8VXngjxNZatYSeXd2EokjPY9ip 9QQSCPQmvu74b+PbP4l+DLHWbJh5d2nzx5y0Mg4ZD7g5+owehFfn/Xrf7JXxnPw58aDSr2Uj R9adY2z0gnOAknsD90+xB/hoA+urq1aR0liIWaPgZ6OO6n29+x9eQXWt4t2rYDI6HDowwyH0 P+PQ1LVe7sjLIs0TCO4QYDY4Yf3W9R/LtUtW1QyxRUNlei6DKymOaPiSMnJX39wex/rkVNTT EFFFFMB9vcSWlxHNExSSJg6sOqkHINcT8bP2etEhNn8QdEudX8NFp75tRl8MWV54g8W2t/qE hSSDQYpvOt9IF60kj3E8US5LFi0R3zr2dWLDV7vSxKLW6uLYTrskEUjJ5i+hx1HsaAO8+FXg 7W/i78ENCg+IMthYfFDTrEf2ibWSOWW13O5hS4EZ8tnMYXzRGfLEvm+W23Brz/x78Prixjud E8Q2CBLyJkdC3mQ3CHgsjdxn1AYcZCkipNJ1a78P6pDfWFw9reQZCSLzweqsOjKcDIPHAPUA j2GRdP8A2i/AAdQtlrenE4G45tZiv3ScfNC4x25GOjp8oB8heA/2RPCvg/T76O7ibWbi9R4v OuVAMCNkYjA+62P4uuemBxXc+A/h3o/w10VbDRrKK0h4MjAZkmYD7zt1Y/Xp2wK3JIpbaaWG eJ4LiB2imib70bqcMpxwcEdRweoyKSgAooooAKKKKACiiuq8C/Cm/wDF5S4lBs9PJz5rD5pR /sDv9Txz3xisMRiaVCDqVZWS/r5gld2Rzul6Vc63fJbWcElxPJ0RBk/U9gPc8CvVPAvwTttH 2XWq+Xe3Q5EOMwx/XP3z9eOehwDWs994W+DfhrU7i71HS9IstGt0utSuLq5RGgjYsEklJOQG IYLnAJBCjtXzR8cP20fGGp2fxA03RtJvNM0iDRYfFfgvV9K8war450mKOJdRtLWCSCRra8hu nSFmaNpBFdRvHCXAavna1fHY9ulh06cO7TTa8v8AgfeaqEY6y18j6k8W+ONO8I6x4f0m8u0s 9V8X3r6ZoySwyNHd3S2lzdtHuUYBEFpcSYJGRGRnJFammiy8CrFbXV6z3Wq3Jk3MpCvK21Tt UDEa52gZ6s4yWd8t8Wfsm/sfeIfi0nhb4heM9W8U+HPF/hTxVFqX9t6eGs7X4l2cELQwXN7p 1woeG4WF5LX7SY4riaBFdmKSiNPq/wASXnhf4daFeWSWNjYwalPcXkllZRLE1zNPI0k0xC4+ d5Gd2kOCWJOc0QjhctapYaLnVdk+9t35JW/S/cbblrJ2R5z8YfAB8A+LXMKkaZqjPPa4HELZ y8PsATlRwNpwB8hNfNX7WX7Ptx8RI7XW9DthNrEJW3uIlwpuYycK2TxlSep/h/3RX2n4Z1G2 +Pnw3utLvnMGp2BVWkyHeJ8HypxgLncAQQAASJF6V45eWU+mX09pdxeRd2khinjznYw7Z7gj BB7gg9DX1CMT4X+CF3o3hT4t2kXivTY5rWOU20i3IIWzm3YDup4IUgghsgZz2r7jjCrGoQKE A4x0xXkfxN/ZK0z4k/EyPW5Lt7KznQG+t4UAeeQcBlPRcjqcE8epJHU+Ovin4b+Avhe1t7y4 bNtCsVrZJJ5tzIqjA+8c4wPvMce+aYHZSzJBE8kjKkaAszMcBQOpJ7Cuc8E/F7w98RNY1Cx0 fUI72fTceaVBCuD/ABIT95QeMjjp6ivkv4yftI698Xpnt3c6bo4bKWULnDDsZG43n8h6Cr/7 Kvxkj+Fvjg2t8UXSdZKwzyEDNu4zsfPZcnDexz2oA+yqKAwYAggg9DWf4o8V6b4L0aXUNVvI LGzh+9JIcDPoB1JPYDJNAGhRXz3dftywT/Eazt7axWLw0JfKuLiYEzsCceYADhVHXGCSB2PF fQcUqzRq6Mro4DKynIIPcUALRW34K+HWr/EGTdp0EYtELLJdzOUhUjI2rgEs2eCAMDByQcAl Amzw7/glp+0FcaKuveDdYbPhy0tn1ZLyZ1WDSwCBKJGYgLG+QR2DZ4+YkeveMNK05ktda0C6 i1Hw3rSmaxuoW3R9SGjz6qQRzzjjqDX5spK8auqsyhxtYA4DDIOD68gH8K+uv+CcHjG/8U+B PHXhK/lFzo2kWP8AbFijZL2k4JzsPZW7jvk9NzZ/mrizIKeb4CVCVlON3GXZrp6PZ/J2ukf0 rxpwzDCTq59Qla7jzQto09G/8V2n0W/V3PR9Y0qPWtPkt5RhXHBxkqexrzG8tXsbuWCTG+Ji rYORkV1nxD1+6sZ47SGTyo5Y9zFeGPJGM9hx2rjq/GOF8NVp0HUlL3ZbLt5nBl8JKF29GFS2 dnLf3CxQxtJI/RQOaZCgkmRTkBiBX0j+zd8KNFvxez3FuZzZOiqkhBSUkE5cY+bGOnTk8V9R Rpzr4mnhKNlKd7N7K2rvbX0XXutzPNszjgaDrSVzQ/ZH0jXtD0WeK8QtpMw3xu3AWQYGE7sC Mgnp8gAPBz5p/wAFN/2Vm+JHhBPHGiWhl1jQoiuoxRL811aDLeZxyWi5PrtJ/ugV9XoixoFV QqqMAAYAFEkazRsjqro4wykZBHoa/aeG/a5PGl7Ko5OHV6db202Xbeytq7H4vmOJ+t1p1pRS 5ui/r7z8IvG3hO78WpbrDKiS2hKushwHBxhxjPXH+cU/w/8ADu38NCO5cG8uozk/KCv/AAEH uOuete0ftgeANM+Fn7THibRNFha2021vQIYi24Ro8Il2D/ZVmIGeQAOTyT59X9KR4qxqwNGh SlajJX5UrXTbvFta2ve1tr+SPgXwnlssxnmdSnzVXbVu6TSSTSel7JfpYl07UZtOu4Lq1meG eBhLFLG2GRgchgR3r7v/AGcPCUX/AAUX8B6rqXxB8W6hqeo6ShsLfR7VfstrpTtGQl4yKf30 rfMQTwCGGCMAfGX7PvgWz+Jnxj0Pw5fyXMNhqV+ltI1uwWREKgnaSCAfqDX6s+BfhN4d+Btp odj4W0q10m3S6+zyeWuXuFdSG8xzlnJKock5yi9uK+NzTFwweKhhWm+e1n5NJq/nqr/M+nhF yi5H5wftP/sfav8As0WGkXk96ur2F+8trPcR27RLa3UbsDEQSeGQBlY43DdgYGT49X65/tH/ AA50n4jaTrOgarbibT9a0a4u5QMB4bi3MYinQ44kAcAk5yEQdAQfyMrPCV5SnUoz1cXv5PVf NbMJLRNBRRRXaSFe6fsH/FjxT4V+J58IeG9e07w2PHTx2cuoXdobo2jpuMbxpkKZDlkUNlSX GcdR4XWz8PPFV34G8e6LrVgyLfaVfQ3duXXcokRwy5HcZA4obA/Uzxvr9t8AvD/g3w7rsY8X eGPEd3Np2rXt5bi6upZ3jlmDtbxRnzlkkBDYXK8Els8ehw+BdO1C0trrTlu9CE8amVLWMWzy ptACSIV4YAKN2A6gYDDmq/wuUeL/AAZ4e17VFhvtXaz8xLmSFA8HmhS6ptA2g7V9zgcmpPCP jK7174h+KdMmWFbXRvsywbFIY+YrsxYk8ngdMdKidOM1aauhpnIfEv47ab8KdEurXQrOKQWK SyT3DAiCEpkyH+9M+QcnOCd2X3AivGPDnj9/itotr4kllvJ31WIShrrHmquThcD5VH+yvyjJ x1ru/iT4ZtPG/wAIdSGoI0hn1rWNPcodhaBr+6Qrkf7IGD9fU14n8aPDNtoX7O+r6bZNcWtt pmnBYPLlZXAjA2gnqQcYOeoJrDCYhVotpWs2vudgasdnpniLT9bubqGzvbW7lsmCXCwyq5hY jIDY6H2NfJX7adlfQfGqae5iZbWe1i+yPj5XQLhhn1D7vzHrVv8AYe1y5sfizcWMchFrf2Tm ZOzFCCp+oyR9GNey/tfeE7LxB8GL+9uYybrR2Se2kXAZSzqjD/dIbkeoHpXUI+SvA/jK++H/ AIqstY0+Ty7qykDgH7sg6Mh9mGQfrX6O/s3/ALTEaeCLW8t7eTUdE1D9+sKSKJ7GQn94ig4V vnySCV5LHJyBX5mV9A/sG+K70eJdX0My7tOa1N6IzzslDomR6ZVuf91fxAPuzxH+07LdWvl6 LpU1tK33ptQ2HZ/upG7bvqWXHoa+f/2jNR8U3vw+1jU9Fv55ddIEs87KHnliGdyx44UgHICj AAIUAkV19FAHxn+zZ8dJ/ht8QXOp3Msul624W+eVyxjcn5ZyTySCTu9QT1IFfYw8ZQ+D9X0u 8TULSzvzcL9gMsoUTykEbAP4gykqQOcMenWviH9o3wzZ+EfjNrdlYReTarKsqxjohdFcgegy xwOwrlr7xPqWp3VrPc395cTWKJHbvJKzGBU+6q5PygY4AoA/Wvx/olr8fPhha61ptvvv7aN8 2r4ZnBwJrZx0LccdiQOdrHP5iftE/CE/CfxuyWqu2jamv2iwc5+VT1jJPdSfrgqepr77/Yd8 e6jraaSlw6MmvaINRugAQPPTyV3qM8ZEhB9dq+lZX7V/wZ8P+MfHFzpN/ZmSylEOq7Vco0cz vIH2kchW2Ekdcu3I4wrgfAXwy+D+u/FrUzb6RaF4oyBNcyfJBB/vN6+wyfavqn4Mfsw6F8Jx HeSqNV1pRn7VMg2wn/pkv8P1OW9wDivQdE0Oz8N6XDZafawWdpbrtjiiQKij6D+ferVMAooo oAiurbz9rK3lyx/cfGceoI7g9x/IgEFrdefuVl8uWP76Zzj0IPcHsf5EECWqmqkxSWsq8Osy p9Q3BH06H6gelS9NRot0UUVQgooooAK1/AfjSb4e+KYdTiV5ICPKvIlGTNDnJwO7qfmX8V43 E1kUUAem/tAeC4rqC38XaWVmtrpI1vTGQVdCAIrgevVVPX5Sp4CHPmVev/s1Xr674L1nS70J d2NpdtbxxSqHXypIldoyDwVy7cHscdMCvJ9W09NH1vUbKJpHisrye2jMjbnKJKyLk9zgDnvQ BBRRRQAVZ0rSbrXL1LazgkuZ36IgyfqewHPU8Ctj4AeBoPi9Bezahd3tobKTYq2hjVXGf4t6 sfyIr2XRvgxoOgQMlqmpQlzl2TU7lDIfU7XA7+lZ1XPlfs7X89gOW8DfBO10bZc6qY726HIi HMMf1z94/XjnpwDXOftb/tL6p+zb8HdV8faL4cl8YaL4JL3/AIotrZXNxHpyRyedLbEfK80D +XK8eGJhinAHmGMN61J8NdEuYmjubI38brtZLyaS6VgRggiRmBBHY9ap+PNWfw5DomnWkNtH a6jdLYunlArHF5bHaq/dAwoGCCME8V4Ecoqe2+t42pz8t7K2n4/1fW5qppK0UfEngXwp4y+P nwj+FXhTxR4P+Idr4utNF0+Dxq+rTyvo3jC1Z4JX1S21ewnaOO9tL4RX9sXngudq3EaBTIXT 3H9mP9hHwv8As7+GJm8Rr4Z8YarDri+Jba6l0dobHQ7yK2W2W6so7u4u5oJzEpMk5uGkdnc7 lUhB7R4J8G6T8N/BuleHdA0+20jQtEtIrGwsbZSsNrBEoSONB2VVAUDsAB2rxn4l+ONR1/VL 6CebFtZzSRxwJ8sfyMQGI7ngcnpzjFZrMa+Oryw2GfIo7vd/L/hwcVBJvW50vxW/aTs/DenX MtrdQW1tbrmXUbkhY0/3Q3U56E8E9Acg18V/FX9uy6vPEMf/AAjkJnt45xJcXd6C0l6ARlQD yqkDGT82MfdxXkPxd+L+u/FTXpH1W6BgtnKw2sWUghwSMhcnn3JJ98VnfDbwvb+MfFUdjdPN HC8E0hMRAbKRM46gjGVHbpXt4PAUcNFqmtXu3q36v+kZttu7Pvv4K/F+GWPSfFmjs09rcR/v oQAXkiJ/eQnnG9SOOcbkHOCc+rfHvwxba9oFr4w0plnhMKG6eMHEtuRlJseqZ54ztJz9wCvh T9g3xXfHXdY0RpS2nC3+2LGefLkDqhI9Mg8/7o/H7x/Zj1Oa70/WtJmKy2NqY5okcZ2ecZfM X/dJTdj1ZvXA7BHk1fOf7a/wZeXZ4w0+Jm2hYdRRR0HRJf5Kf+A+5r6Z8S6TD4f8Uapp9uGF tY3TwwhjkqgPC574HGTzgc5PNZmoafBq1hNa3MST29whjljcZV1IwQfYigD86a7v4P8A7Pmv fGG6V7SL7FpanEl/OpEQweQg6u3sOPUiu8/Z9+B3h/xT8WvFFrqEE11aeHbySK2gd/3cgErK PM4y2Ao4yAe4NfRGreWdRtdAWGKLTr6ynR1izG0agKoCFSNvDHp04xigDzTxt+0RovwB8K2v hywvJfE2tabCLfMjgrEQMDzGXjI6bRlsDBIPJ+cvFnjjxJ8bPFERvJbrU72dtlvawoSqZ/hR B0/n6k1i6rpyWPiG5tELmKG4aFSSNxAYjn3xX3V8B/hboPwV8F6rrWk6fDPqOkaHc6wst3+8 a4mhhMqLIRg+XuAyqlc4oA8n+HX7BzeBvDreKfiTNDpmmWdsb2aB5MxWqAKcTFNzFzuUCJAX YuoG4sBX05+zqnw7+KHh+XUotVuINO0nVz4bbRtY0yXQrm2vYyAlvNbXASVfNRoZYomRS8Us bYZXwPnif4dReMfAOpatNrXim1/4TT4sR+CNTsrfWbhbKTTpXitY2WIsQt3blYpobwf6Sj28 KmVoUENeh/ADwrfeGv2oPFGuXviTWvEWs+LPB1zq2o3WpRWmHuNJ1FrKykSGGCOGNki83LrG HYzNliqRLGmwPcvHn7QM0DnTfDFutlBakRG7ng2428bIojjAGMbmA6EBcENRXm97ey6jezXE 7mSa4dpJGIwWYnJP50UwP//Z --------------030309080908010900030009-- From magnus.westerlund@ericsson.com Thu Jun 7 05:46:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599FE21F85FC for ; Thu, 7 Jun 2012 05:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.695 X-Spam-Level: X-Spam-Status: No, score=-106.695 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU9bmWGgy2ZE for ; Thu, 7 Jun 2012 05:46:11 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0E24821F84E4 for ; Thu, 7 Jun 2012 05:46:10 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-b9-4fd0a2913ba2 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A5.08.11869.192A0DF4; Thu, 7 Jun 2012 14:46:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Thu, 7 Jun 2012 14:46:09 +0200 Message-ID: <4FD0A291.7000005@ericsson.com> Date: Thu, 7 Jun 2012 14:46:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------050600000805020705090301" X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0iTURiAO7t8fo6U4zR9M6IaRWVqZhaCEitEFH9YmSRS5tAPHa2pm5U/ DGYxly40KW1qpeRK8YJN8oJuoIaEYjkvWROVwlHWNPBG6cjavrNA6N9z3vO8vJdzaK5wju9P S+W5jEIukYkoAa8y6fetoLJn5vgQ62p4eMumxk2MYvT6dc5ZlCyITGdk0huM4uipVEFmhSEn uzM0r16lo1SoNKgYudOAw8BeWepG2BfMs61UMRLQQjyE4N7aOJccXiCY05p4TssDH4GpRj1y Mg/vh5L2NjabwuFg+VVAOXkHToB54wSf+F4wWGllc33wQRj/bHb4NO2NxdBT4+lEIT4LK5sn nYY7PgcFWhNF+tkJs5omF1+Cr0YdW4nr0AtrS9m40NGN6vZd/n3kVbWlWNUWjfBhUHfa3Qjv gc7Fx1zCl2GlcJL3fzwdtHVq1gecCpZuC+sI8UsEfQ35VexWqjmw1PTvYhRB26iAXIwgWC/s ochhDYF6oJ5PrHywT2+4Ec6DqU0TRTgHllYtiHAs2MofsUzhQ7C+8In1fXASVBj1LDv3vtKr ZVv1xhFQN1HtcsQw/tbg4mCYbi6myFrOw4MGO9vDdkdu72AXh3Ac6FrG2AmQ4/V/DjVzyPh+ MGWt4ZDxA2GhrNrFUfB+pd61Fgx64wiX8G5YqHnKr0WBjcj7mkQqy7gZGswopGlKZZY8WMm0 IcdH7XtlP9CFpt/59KNdNE/k5xHRbowX4gxJLnOVYbIZxRXFdRmj7Ecc2t1fhQwx6uFvryO/ zLSkhTY8T1GGXIyWl88nMmMlKe1vordpbBZx0bLowlREraj7zAZv30D2RqDt9In8gFjb6EjR ssrKT6CTfyg/GDJ0HeqquKb54614btiEH/6J6shd/Dgj/e4bqamWNE+GpZkTTT3yGJ3clKW+ 07zX9kTkmWjME/GUmZJjAVyFUvIX0KGxZHYDAAA= Subject: [rtcweb] Fwd: Invitation: Monday night get-together in Stockholm X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 12:46:12 -0000 --------------050600000805020705090301 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Forwarding as Harald's message appears to not have reached the list. /Magnus --------------050600000805020705090301 Content-Type: message/rfc822; name="Invitation: Monday night get-together in Stockholm.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Invitation: Monday night get-together in Stockholm.eml" X-Mozilla-Keys: Received: from sesbmg10.ericsson.net (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.95) with Microsoft SMTP Server id 8.3.264.0; Thu, 7 Jun 2012 11:21:38 +0200 Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLS with cipher AES256-SHA (AES256-SHA/256 bits)) (Client did not present a certificate) by sesbmg10.ericsson.net (Symantec Mail Security) with SMTP id BC.D5.12268.1A270DF4; Thu, 7 Jun 2012 11:21:37 +0200 (CEST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1ScYsn-00008E-QA for public-webrtc-dist@listhub.w3.org; Thu, 07 Jun 2012 09:19:57 +0000 Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1ScYsm-00007S-9y for public-webrtc@listhub.w3.org; Thu, 07 Jun 2012 09:19:56 +0000 Received: from mail-qc0-f171.google.com ([209.85.216.171]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1ScYse-0000wn-Pm for public-webrtc@w3.org; Thu, 07 Jun 2012 09:19:54 +0000 Received: by qcsp15 with SMTP id p15so178121qcs.2 for ; Thu, 07 Jun 2012 02:19:23 -0700 (PDT) Received: by 10.229.136.138 with SMTP id r10mr431922qct.72.1339060763219; Thu, 07 Jun 2012 02:19:23 -0700 (PDT) Received: by 10.229.136.138 with SMTP id r10mr431916qct.72.1339060762952; Thu, 07 Jun 2012 02:19:22 -0700 (PDT) Received: by 10.229.5.205 with HTTP; Thu, 7 Jun 2012 02:19:02 -0700 (PDT) From: Harald Alvestrand To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Thu, 7 Jun 2012 11:19:02 +0200 Subject: Invitation: Monday night get-together in Stockholm Thread-Topic: Invitation: Monday night get-together in Stockholm Thread-Index: Ac1EjvDZ/0t2X+cBS5mY+IbCVjdp2Q== Message-ID: List-Help: List-Unsubscribe: Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0247.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb3c-b7f9f6d000002fec-c4-4fd072a0e2cb x-brightmail-tracker: H4sIAAAAAAAAA01Ta0wTWRjtnU6nQ2XMdRD5rKixKrtqFJttshOXuP5Yd9VE8fHD6B9tl7Ft gAFnitbErC0Rg6hQYfEBSjAYQYi8JEQ2KoivKD7Ky0pRxIhmFaMCQmR91E6HFf/cnPnOOd93 vpu5tJoNUHqadzp4UTAnGSgd6Zph4haeEr3xizOf/8xllU3jvMevIq629CzB3b/2CHFvfNe1 nDtd4mpa8hHXVtVDcDkBiXvgGyS49pobJPf4c72aa2waobh9PafRsokr/hvupNaizbq4BD7J voMXY5du1dlyvZ+0qY8YZ+VHv9aF/BOyEE0DNsHw5yAMC8Ip4O2porKQjmZxIQHt1QOkTLC4 HcHdzuXj+GakIhpFUNh/mVKI3XD2ckfITeLDGrie6dLIH4DPaSA9d1ijqJzg/3JpzLEdBt53 IRkzeBLcOt43Nm4l9OcfDdUp/COMvu7VypjEc2Co6YBa0a+FJ/+WhvpMxvPgnxcnQliNV0G2 u0ut7APwvuoZpYS4gGDwUMnYYBsU56SPieaCu7cFKbgaQWt5ooLjobXjA6Xg2fAwvTgUIgL/ AiUdhSGMsBXyj1USSs9Z4H9dTil3ugSqG8MUazScrBgi5DKLF0D2HUEuY4yh6HQD4UExBd9t X/DdBgVBhxr/AFVFrFKOge76Tq2CF8CZU/3qYqQpR5ESL1mSrcbFi3jR/qckpQiLBN5Ri4L/ 1ZW6j3EX0NM+YzOaShOGSMaw3RvPTrSkJOyymSXbFjEtiZea0TSaNEQxL3enxbPYanbwiTyf yov/s9E0bQDmvOycJPJW3rnNnuQYpwk6rBkBHW6YzIzIGkZKNSdLdqvC30a/0q1X7vkQ7bsq n1/6WoNnr6fNh1hSSBF4fRRTKtuwbLOlCd86y+9iTyAQaEPT9REMUqlUbHgwVbLdMc7L7+YV iqKRIYJpk7uE2wXHt9mvgrGIYKyMzaFYDvM4pXchU30WPjd6pEt/MdPf8vuKuL0574wa1V8V B3+aMqO2Yb9nzc7Hz1x5bw8f3UDmrSvbeimR+KPOPbSP10lrLBGbTGLkAdNvYRu77Ren61o8 wlD0YOzJjL+dbmNuhqfiU50t/HzeyMzVA8uN64u2lOzluvfXNpSrsg9admTPi7VMKEuIMZCS zWycrxYl81cOWj8nEgQAAA== dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=gmKUYR6HtbCtem2c6KwiQrf2aldSLaJCWciHWMSsuKs=; b=GH7tjwAMmAT6UBIZZLiHD6Rpb3NdTIlkARybQxyUDlZWChPDmys2pzhAzEQzDgd7u/ H0suOQErSgX2rS2ATMX2d/0jZZPYOS8+hg2iVt7CvyekG0I7u2lMco7lNHmaKN8jHdfN lRSbu6ZaETi5R/Wcy3mumFEeqfA+outs/nNJ3XitytdnOvlRjfCHyLvqfQPrun9lZq9i 7k6aRmGLbuoX2unVhIIqKebNiOEM7GyJyeoz7GNFOZA7IHAWLJYHGNfdskihXmybPjJG IUpwRR37J01bREvNkyQgNuJkTR9kAaOTu9GvLi5/mo8U56BLFwTWurgHJRJ2gjC7adQ3 1IYw== list-post: list-id: x-loop: public-webrtc@w3.org received-spf: pass client-ip=209.85.216.171; envelope-from=hta@google.com; helo=mail-qc0-f171.google.com x-original-to: public-webrtc@w3.org Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 PGRpdj5IZWxsbyw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmFzIHBhcnQgb2YgdGhlIFdFQlJU Qy9SVENXRUIgbWVldGluZ3MgaW4gU3RvY2tob2xtIG5leHQgd2VlaywgR29vZ2xlIHdvdWxkIGxp a2UgdG8gaW52aXRlIGFsbCB0aGUgcGFydGljaXBhbnRzIHRvIGEgZ2V0LXRvZ2V0aGVyIGF0IHRo ZSBHb29nbGUgb2ZmaWNlcyBpbiBTdG9ja2hvbG0gb24gTW9uZGF5IG5pZ2h0LCBKdW5lIDExLCBh cm91bmQgNyBQTS48L2Rpdj4NCg0KPGRpdj48YnI+PC9kaXY+PGRpdj5UaGVyZSB3aWxsIGJlIGZv b2QgYW5kIGRyaW5rcyBhdmFpbGFibGUsIGFuZCB3ZSBleHBlY3QgcGxlbnR5IG9mIG9wcG9ydHVu aXR5IGZvciBtaW5nbGluZyBhbmQgdGFsa2luZy48L2Rpdj48ZGl2PkluIG9yZGVyIHRvIGhhdmUg YW4gYWNjdXJhdGUgY291bnQgZm9yIHRoZSBjYXRlcmVycywgaWYgeW91JiMzOTtyZSBjb21pbmcs IHBsZWFzZSBzaWduIHVwIGhlcmU6PC9kaXY+DQoNCjxkaXY+PGJyPjwvZGl2PjxhIGhyZWY9Imh0 dHBzOi8vZG9jcy5nb29nbGUuY29tL2EvZ29vZ2xlLmNvbS9zcHJlYWRzaGVldC92aWV3Zm9ybT9m b3Jta2V5PWRGUmlSSGQ0TVZwUFVYQkdhRXRIUWs5ak5sZzFUWGM2TVEiPmh0dHBzOi8vZG9jcy5n b29nbGUuY29tL2EvZ29vZ2xlLmNvbS9zcHJlYWRzaGVldC92aWV3Zm9ybT9mb3Jta2V5PWRGUmlS SGQ0TVZwUFVYQkdhRXRIUWs5ak5sZzFUWGM2TVE8L2E+PGRpdj4NCg0KPGJyPjwvZGl2PjxkaXY+ V2VsY29tZSB0byBTdG9ja2hvbG0hPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj7CoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoEhhcmFsZCBBbHZlc3RyYW5kPC9kaXY+PGRpdj48YnI+PC9kaXY+ DQo= --------------050600000805020705090301-- From fluffy@cisco.com Fri Jun 8 05:23:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7B821F88D2 for ; Fri, 8 Jun 2012 05:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.949 X-Spam-Level: X-Spam-Status: No, score=-110.949 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 dRT5O+6PcpAL for ; Fri, 8 Jun 2012 05:23:17 -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 3D48C21F88AA for ; Fri, 8 Jun 2012 05:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2198; q=dns/txt; s=iport; t=1339158197; x=1340367797; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZlmG3Si/lCmQgzTq+lAo+o5GQ2a/r/8PV0Zr+kCJp/8=; b=FyNsvr9Wt5FuEZbcYDQMGEWcMb7nxfYAVJZM+u0yq/9OuqBPyjK3cFFD sJooqx7oajc9T6Im4it3n5n370//wMigJTSGVjAJ1YvdjeP6q5v9zYMIW V/Q2E3I3DPcrrZI256LT5nAFtp7MNxU585FIjz2cVKm5815F8rJlfAVXt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANXt0U+rRDoH/2dsb2JhbAA7CrROgQeCGAEBAQQSAWYMBAsRBAEBKAdGCQgGExsHh2iZNZ9xiyYQhRBgA5FCg1yFU4hCgWaCfA X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="48178507" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 08 Jun 2012 12:23:17 +0000 Received: from [10.86.244.114] ([10.86.244.114]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q58CNFXU030957; Fri, 8 Jun 2012 12:23:16 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Fri, 8 Jun 2012 08:23:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> To: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= X-Mailer: Apple Mail (2.1278) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 12:23:18 -0000 On May 30, 2012, at 5:06 , G=F6ran Eriksson AP wrote: >>=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org=20 >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings >> Sent: den 16 maj 2012 03:31 >> To: rtcweb@ietf.org >> Subject: [rtcweb] Comments on=20 >> draft-ietf-rtcweb-use-cases-and-requirements-07 >>=20 >>=20 >> Like to add case where application has one two video streams=20 >> but one is far more important than the other. Should be a way=20 >> to make sure that preferential treatment is given the the=20 >> important stream over the less important streams.=20 >=20 > I agree that this is a relevant area to address to secure that WebRTC = is competitive compared to > apps done in native OS's, especiallin in enterprise context. >=20 > The current use case document states something like "being able to use = priority functions in network nodes". > This is vague since it touches many matters such as whether to put = audio and video on the same IP-flow or have them in different > ones, which is essential when considering mapping on LTE radio = channels; the potential use of DS to identify flows, which > may be relevant in enterprise context, etc, how to cater for treament = of stuff on the datagram channel, multihoming consequences, etc. >=20 > I am not sure however how far into such matters we should go in this = WG, but given the importance of making a > good solution working across OS's and browser vendors and access = technologies, I am leaning towards support a discussions about such > details in this WG for instance using the use case document. >=20 > What is Your take of this?=20 I think we need to discuss it in the spec. Let's imagine the case where = we want the brows to set one DSCP for audio and a different one for = video. I don't think we can have setting the DSCP 100% under control of = the JS App as that has security problems. But the browser should set the = DSCP to something and if there are multiple video streams, I think it is = important to be able to indicate some video streams are less important = than others - only the JS app knows which one is less important.=20 From goran.ap.eriksson@ericsson.com Fri Jun 8 05:52:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DC221F8872 for ; Fri, 8 Jun 2012 05:52:00 -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 YBkVNVhztWfx for ; Fri, 8 Jun 2012 05:52:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 47D1021F87F5 for ; Fri, 8 Jun 2012 05:51:18 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-18-4fd1f543616c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5C.E4.28636.345F1DF4; Fri, 8 Jun 2012 14:51:15 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.214]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 8 Jun 2012 14:51:14 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Cullen Jennings Date: Fri, 8 Jun 2012 14:51:14 +0200 Thread-Topic: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 Thread-Index: Ac1FcX09P8EEp4k7S+25UPIUHkal/QAABb3w Message-ID: References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvra7z14v+Bs8vq1p0TGazWPuvnd2B yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyjh2tZm54L9MRceMQywNjJPFuxg5OSQETCQO vzrDCmGLSVy4t56ti5GLQ0jgFKPE/+4dTBDOAkaJU6cXsoNUsQl4S0xbcRasQ0RATaJhxSOw OLOAusSdxefAbBYBFYlvN38ygdjCAsESBzfsZYOoD5G4OvEMO4RtJHHlyW1mEJtXIFzi8eEF zBDL9jJKHGzbBtbMKWArcXHNE7BmRgFZifvf77FALBOXuPVkPhPE2QISS/acZ4awRSVePv7H ClEvI3Fq0X9WiHo9iRtTp7BB2NoSyxa+hlosKHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxi FM5NzMxJLzfUSy3KTC4uzs/TK07dxAiMnoNbfuvuYDx1TuQQozQHi5I4L1fSfn8hgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjFGbqvZ5s+uttvmxtn3zMqMjl4o6Zcpie6/2G87qMpq2iNnb uLf0PvN2ywo1k8uy7WdnXAvN2rc07skNngOLZS+3fn7ItM3603+fxoRWlyjjg7ctf+2xKj8s eXuX3UrxYsau1WvfhYSHH57HUR2rGZzSGMOS8uA+p3KZoEXngsXzvLo7MzIWKbEUZyQaajEX FScCAOMmmAVsAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 12:52:00 -0000 =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: den 8 juni 2012 14:23 > To: G=F6ran Eriksson AP > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Comments on=20 > draft-ietf-rtcweb-use-cases-and-requirements-07 >=20 >=20 > On May 30, 2012, at 5:06 , G=F6ran Eriksson AP wrote: >=20 > >>=20 > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org > >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings > >> Sent: den 16 maj 2012 03:31 > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] Comments on > >> draft-ietf-rtcweb-use-cases-and-requirements-07 > >>=20 > >>=20 > >> Like to add case where application has one two video=20 > streams but one=20 > >> is far more important than the other. Should be a way to make sure=20 > >> that preferential treatment is given the the important stream over=20 > >> the less important streams. > >=20 > > I agree that this is a relevant area to address to secure=20 > that WebRTC=20 > > is competitive compared to apps done in native OS's,=20 > especiallin in enterprise context. > >=20 > > The current use case document states something like "being=20 > able to use priority functions in network nodes". > > This is vague since it touches many matters such as whether to put=20 > > audio and video on the same IP-flow or have them in different ones,=20 > > which is essential when considering mapping on LTE radio=20 > channels; the potential use of DS to identify flows, which=20 > may be relevant in enterprise context, etc, how to cater for=20 > treament of stuff on the datagram channel, multihoming=20 > consequences, etc. > >=20 > > I am not sure however how far into such matters we should=20 > go in this=20 > > WG, but given the importance of making a good solution=20 > working across=20 > > OS's and browser vendors and access technologies, I am=20 > leaning towards support a discussions about such details in=20 > this WG for instance using the use case document. > >=20 > > What is Your take of this?=20 >=20 > I think we need to discuss it in the spec.=20 >Let's imagine the=20 > case where we want the brows to set one DSCP for audio and a=20 > different one for video. I don't think we can have setting=20 > the DSCP 100% under control of the JS App as that has=20 > security problems. But the browser should set the DSCP to=20 > something and if there are multiple video streams, I think it=20 > is important to be able to indicate some video streams are=20 > less important than others - only the JS app knows which one=20 > is less important.=20 Agree that the JS controlling the DSCP marking is an issue- I am more leani= ng towards looking to solutions putting the "origin" in control. Also, the server side= of the "app" should also be able to in a position to understand the relati= ve importance on the different streams/flows in an application. But this is of course up for discussion. Another set of use cases could be considering the data on the data channel-= we have scenarios where these have a significant impact on the UX and it c= ould therefore be relevant to consider these flows as well- after all, it may be nice talking= to/looking at someone but if we also expect some shared data, I am pretty = sure we will spend time complaining on the "darn" network more than doing w= hatever was the original purpose, :-)! Going forward, I think Your proposal for adding use cases detailing require= ments in this area is a very good one and a good, next step. I expect this will be brough= t up in next week interim meeting for a discussion about how to proceed. >=20 >=20 >=20 > = From g.kiranreddy4u@gmail.com Sat Jun 9 04:26:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C1221F89A9 for ; Sat, 9 Jun 2012 04:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytpTKOtp2LYT for ; Sat, 9 Jun 2012 04:26:27 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB19321F8812 for ; Sat, 9 Jun 2012 04:26:26 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so5112463obb.31 for ; Sat, 09 Jun 2012 04:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=I3kNvMT5M/pS9ooT8OKb3T4nY6UV26waX2H82hKHbus=; b=jLiNbHOmGwX8OvlUDkBe0Nxz05J7nN+4x8+h2YCey5K5zp2PfkIENnunT2KkcpTQez eityRTKcn4b/f6ILLhZ4F6+KPOGLZgDLovkNQTdAfDtpqzajvVxrcPv6T2J0Lv2s4Ymy szroBsACeVD5vBYL9UOA7f8RAlY5zCUgazYtouWUisDYUUkA1aeaSLDh6wuQkH4TDrwN RXIiSizB5JhynEnBtyqowy6klPkXbSoWHXddOdmzr/MIqTFouseEnsvzatY4Vm7GlZJv VZrePBYGoVl9CrlVkeArPf64PMpTLOYZAM8DD3YYk+83gXw3lqNF7YcRW9ZylYmQXOOr COZA== Received: by 10.50.135.37 with SMTP id pp5mr66346igb.33.1339241186227; Sat, 09 Jun 2012 04:26:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.135.5 with HTTP; Sat, 9 Jun 2012 04:26:06 -0700 (PDT) From: kiran kumar Date: Sat, 9 Jun 2012 16:56:06 +0530 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=e89a8f83a12f2c761404c20863ca Subject: [rtcweb] Reg retransmissions using JSEP approach. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 11:26:27 -0000 --e89a8f83a12f2c761404c20863ca Content-Type: text/plain; charset=ISO-8859-1 Hi all, I am new to this list, so please don't mind if I am repeating the same question, if it has already discussed in this list. My doubt is regarding how JSEP style of implementation will differentiate the retransmission of messges with out ROAP. According to few mails and discussion lists, It is specified that ROAP is going to be replaced by JSEP. But in updated JSEP draft an example with ROAP is also provided. If ROAP is going to be replaced by JSEP, which part of JSEP will differentiate the retransmitted offers. ROAP is having "seq" field to differentiate it. Is that part going to be completely left to the application protocol ? Thanks, Kiran. --e89a8f83a12f2c761404c20863ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
I am new to this list, so please don't mind if I am repeating the = same question, if it has already discussed in this list.
=A0
My doubt is regarding how JSEP style of implementation will differenti= ate the retransmission of messges with out ROAP.
=A0
According to few mails and discussion lists, It is specified that=A0RO= AP is going to be replaced by JSEP.
But in updated JSEP draft an example with ROAP is also provided.
=A0
If=A0ROAP is going to be replaced by JSEP, which part of JSEP will dif= ferentiate the retransmitted offers.
ROAP is having "seq" field to differentiate it.
Is that part going to be completely left to the application protocol ?=
=A0
=A0
Thanks,
Kiran.
=A0
--e89a8f83a12f2c761404c20863ca-- From pravindran@sonusnet.com Sat Jun 9 11:35:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3127721F853D for ; Sat, 9 Jun 2012 11:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.225, 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 nZLZ-rPPQhBr for ; Sat, 9 Jun 2012 11:35:01 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 71A4A21F853C for ; Sat, 9 Jun 2012 11:35:01 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT9OXUrJvxiWPfUL3BPRhtdZYT8go7DyC@postini.com; Sat, 09 Jun 2012 11:35:01 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 9 Jun 2012 14:35:29 -0400 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Sun, 10 Jun 2012 00:04:52 +0530 From: "Ravindran, Parthasarathi" To: kiran kumar , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Reg retransmissions using JSEP approach. Thread-Index: AQHNRjLSgZuO1wadjkqdAUrxgMhR95byT/lQ Date: Sat, 9 Jun 2012 18:34:51 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16046E98@inba-mail02.sonusnet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C16046E98inbamail02sonus_" MIME-Version: 1.0 Subject: Re: [rtcweb] Reg retransmissions using JSEP approach. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 18:35:03 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C16046E98inbamail02sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kiran, As per JSEP, it is left to the application protocol. The application protoc= ol shall have "seq" field equivalent to differentiate the retransmitted off= ers. Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= kiran kumar Sent: Saturday, June 09, 2012 4:56 PM To: rtcweb@ietf.org Subject: [rtcweb] Reg retransmissions using JSEP approach. Hi all, I am new to this list, so please don't mind if I am repeating the same ques= tion, if it has already discussed in this list. My doubt is regarding how JSEP style of implementation will differentiate t= he retransmission of messges with out ROAP. According to few mails and discussion lists, It is specified that ROAP is g= oing to be replaced by JSEP. But in updated JSEP draft an example with ROAP is also provided. If ROAP is going to be replaced by JSEP, which part of JSEP will differenti= ate the retransmitted offers. ROAP is having "seq" field to differentiate it. Is that part going to be completely left to the application protocol ? Thanks, Kiran. --_000_387F9047F55E8C42850AD6B3A7A03C6C16046E98inbamail02sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kiran,

 <= /p>

As per JSEP, it is left t= o the application protocol. The application protocol shall have “seq&= #8221; field equivalent to differentiate the retransmitted offers.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of kiran kumar
Sent: Saturday, June 09, 2012 4:56 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Reg retransmissions using JSEP approach.

 

Hi all,

 

I am new to this list, so please don't mind if I am = repeating the same question, if it has already discussed in this list.=

 

My doubt is regarding how JSEP style of implementati= on will differentiate the retransmission of messges with out ROAP.

 

According to few mails and discussion lists, It is s= pecified that ROAP is going to be replaced by JSEP.

But in updated JSEP draft an example with ROAP is al= so provided.

 

If ROAP is going to be replaced by JSEP, which = part of JSEP will differentiate the retransmitted offers.

ROAP is having "seq" field to differentiat= e it.

Is that part going to be completely left to the appl= ication protocol ?

 

 

Thanks,

Kiran.

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C16046E98inbamail02sonus_-- From fluffy@iii.ca Sun Jun 10 07:21:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B20F21F85DA for ; Sun, 10 Jun 2012 07:21:43 -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=[BAYES_50=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 mwn5QRuDtzXG for ; Sun, 10 Jun 2012 07:21:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BE1D921F85D2 for ; Sun, 10 Jun 2012 07:21:42 -0700 (PDT) Received: from rtp-vpn4-1789.cisco.com (unknown [64.102.254.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2E9F022E253; Sun, 10 Jun 2012 10:21:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Sun, 10 Jun 2012 10:21:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13D57612-5ADF-4B23-B7A4-81B212D49C66@iii.ca> References: To: kiran kumar X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reg retransmissions using JSEP approach. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 14:21:43 -0000 On Jun 9, 2012, at 7:26 , kiran kumar wrote: > Hi all, > =20 > I am new to this list, so please don't mind if I am repeating the same = question, if it has already discussed in this list. > =20 > My doubt is regarding how JSEP style of implementation will = differentiate the retransmission of messges with out ROAP. > =20 > According to few mails and discussion lists, It is specified that ROAP = is going to be replaced by JSEP. > But in updated JSEP draft an example with ROAP is also provided. > =20 > If ROAP is going to be replaced by JSEP, which part of JSEP will = differentiate the retransmitted offers. > ROAP is having "seq" field to differentiate it. > Is that part going to be completely left to the application protocol ? > =20 Yes, I think the idea i the application would have to deal with that. It = probably needs to keep track of the keeping between the offer / answers = to the seq number too so that if an offer is rejected and it rolls back = to reg previous offer, it has that offer so it can roll back. At the = same time browser implementation also need to keep track of the various = offers so they can roll back. More text is needed in the drafts on all = this.=20 From fluffy@iii.ca Sun Jun 10 07:21:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DF921F85D2 for ; Sun, 10 Jun 2012 07:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, MIME_8BIT_HEADER=0.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 GRuIBUD82US7 for ; Sun, 10 Jun 2012 07:21:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BE44121F85D4 for ; Sun, 10 Jun 2012 07:21:42 -0700 (PDT) Received: from rtp-vpn4-1789.cisco.com (unknown [64.102.254.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8CD1322DD6D; Sun, 10 Jun 2012 10:21:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Sun, 10 Jun 2012 10:21:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FCF0EAC.3040900@alvestrand.no> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1278) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 14:21:43 -0000 On Jun 6, 2012, at 14:54 , I=F1aki Baz Castillo wrote: > 2012/6/6 Harald Alvestrand : >> That's what ICE/STUN discovery is for.... and once you yank out your = cable >> or reconnect your wireless, it all changes anyway, so caching has = very >> limited value. >=20 > Sure, but in my case it means ~3 seconds of delay for every WebRTC > session. Just wondering: it would be "nice" if the SO would notify the > browser when some change in the network settings happen, so the > browser would then invalidate its cache and try again all the > interfaces, and not just those that worked in the previous session. >=20 I get that the VPN takes however long to timeout, but given that other = STUN servers do respond, why are you dealing your whole WebRTC session = waiting for that stun server. Just ignore it once you get some response = from another interface.=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Sun Jun 10 08:33:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E719421F85C6 for ; Sun, 10 Jun 2012 08:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-Q8ANUtvRv1 for ; Sun, 10 Jun 2012 08:33:20 -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 5912C21F85AA for ; Sun, 10 Jun 2012 08:33:20 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CF2701EB84E3 for ; Sun, 10 Jun 2012 17:33:18 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Sun, 10 Jun 2012 17:33:18 +0200 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 Thread-Index: AQHNRXWCXu14Kzuy2EiOwUV/KKjYHJbzfIYA Date: Sun, 10 Jun 2012 15:33:17 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.249.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 15:33:21 -0000 Hi, Some comments on draft-ietf-rtcweb-use-cases-and-requirements-07. Section 4.1.1.1 (Simple Video Communication Service) contains the statement= "Each user can also pause sending of media (audio, video, or both) and mut= e incoming media". I think this and the associated requirements need some = clarification for example whether the requirement is to control the directi= on of the media and therefore requires the generation of a new SDP offer wi= th for example a direction of "recvonly/inactive". The only associated req= uirement seems to be A8 but this does not help clarify what is meant by "pa= use" in the use case. It needs to be clarified whether the pause/resume/mut= e are actions within the browser or are actions which result in notificatio= ns to the remote user. Maybe we could add a use case which involves controlling the direction of m= ultiple streams to emulate switching between different users in a multipart= y call scenario. The statement "It is essential that the communication cannot be eavesdroppe= d" appears in all use cases so could be moved to section 4.1 but I think it= needs to be reworded in terms of the media always being encrypted as I don= 't like the term "eavesdropped" which is not defined. Regards Andy From ted.ietf@gmail.com Sun Jun 10 09:48:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B79821F85A0 for ; Sun, 10 Jun 2012 09:48:22 -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 TQ2IyizwZhw3 for ; Sun, 10 Jun 2012 09:48:21 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42EA921F8597 for ; Sun, 10 Jun 2012 09:48:21 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2091460vcq.31 for ; Sun, 10 Jun 2012 09:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lzggdgYfRz+CmhrwZaznr/nT6kZTmxIp2bP7AGRRSR0=; b=CkM4wk1GiRYZL6QjM1uyQ4RzFmO7jcQVL5ta11/7/R8uieV3gBpFy8L3T1AxyKEH/G VQgCq30jGkpKPP32/MDXo/L2yev6dK2DzMfi0qK6l+ZV5BFyEFUVkw9+1dTMwkraec8l pGaz999pMkbZX5ky6NkD3lmfBBgq3+ThVeGHb9g3kU1XPkyx5JWg4hj3uI8USQtH24cW o4SxKX+QlcQhJdNYQpp2r40AGD9FWgnagem7bNvMeAsnA7aiJeh1goH+X19+XhNG2uGu zYb1IOtnd5EKQJHdJVgVAPC3EOWZY13QSCFMo5N0Wd9VNUNsKiiPgmeb8K4BFPLBPIRo qsgQ== MIME-Version: 1.0 Received: by 10.52.21.99 with SMTP id u3mr9417371vde.56.1339346900272; Sun, 10 Jun 2012 09:48:20 -0700 (PDT) Received: by 10.52.37.51 with HTTP; Sun, 10 Jun 2012 09:48:20 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> Date: Sun, 10 Jun 2012 18:48:20 +0200 Message-ID: From: Ted Hardie To: "Hutton, Andrew" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 16:48:22 -0000 On Sun, Jun 10, 2012 at 5:33 PM, Hutton, Andrew wrote: > Hi, > > Section 4.1.1.1 (Simple Video Communication Service) contains the stateme= nt "Each user can also pause sending of media (audio, video, or both) and m= ute incoming media". =A0I think this and the associated requirements need s= ome clarification for example whether the requirement is to control the dir= ection of the media and therefore requires the generation of a new SDP offe= r with for example a direction of "recvonly/inactive". Howdy, As a clarifying question, are you thinking that it is not clear because non-signaling methods could achieve some of these? That is "muting" incoming media could also be accomplished entirely receive side, by simply not rendering it? regards, Ted =A0The only associated requirement seems to be A8 but this does not help clarify what is meant by "pause" in the use case. It needs to be clarified whether the pause/resume/mute are actions within the browser or are actions which result in notifications to the remote user. > > Maybe we could add a use case which involves controlling the direction of= multiple streams to emulate switching between different users in a multipa= rty call scenario. > > > The statement "It is essential that the communication cannot be eavesdrop= ped" appears in all use cases so could be moved to section 4.1 but I think = it needs to be reworded in terms of the media always being encrypted as I d= on't like the term "eavesdropped" which is not defined. > > Regards > Andy > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Sun Jun 10 13:03:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0967C21F8523 for ; Sun, 10 Jun 2012 13:03:11 -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 hqv0B0iyeebE for ; Sun, 10 Jun 2012 13:03:10 -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 0CFF021F850F for ; Sun, 10 Jun 2012 13:03:09 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id C564423F0412; Sun, 10 Jun 2012 22:03:08 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Sun, 10 Jun 2012 22:03:08 +0200 From: "Hutton, Andrew" To: Ted Hardie Thread-Topic: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 Thread-Index: AQHNRXWCXu14Kzuy2EiOwUV/KKjYHJbzfIYAgAAotgCAAFaAYA== Date: Sun, 10 Jun 2012 20:03:07 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 20:03:11 -0000 Hi Ted, See below. Regards Andy > -----Original Message----- > From: Ted Hardie [mailto:ted.ietf@gmail.com] > Sent: 10 June 2012 18:48 > To: Hutton, Andrew > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and- > requirements-07 >=20 > On Sun, Jun 10, 2012 at 5:33 PM, Hutton, Andrew > wrote: > > Hi, > > >=20 > > Section 4.1.1.1 (Simple Video Communication Service) contains the > statement "Each user can also pause sending of media (audio, video, or > both) and mute incoming media". =A0I think this and the associated > requirements need some clarification for example whether the > requirement is to control the direction of the media and therefore > requires the generation of a new SDP offer with for example a direction > of "recvonly/inactive". >=20 > Howdy, >=20 > As a clarifying question, are you thinking that it is not clear > because non-signaling methods could achieve some of these? That is > "muting" incoming media could also be accomplished entirely receive > side, by simply not rendering it? >=20 Yes I guess so it is not clear whether the use case results in a local acti= on in the browser or it whether it impacts the media and SDP. I want to mak= e sure that it is possible to control the media direction in SDP (sendrecv/= recvonly/sendonly/inactive) and have the browser behave appropriately. > regards, >=20 > Ted >=20 > =A0The only associated requirement seems to be A8 but this does not help > clarify what is meant by "pause" in the use case. It needs to be > clarified whether the pause/resume/mute are actions within the browser > or are actions which result in notifications to the remote user. > > > > Maybe we could add a use case which involves controlling the > direction of multiple streams to emulate switching between different > users in a multiparty call scenario. > > > > > > The statement "It is essential that the communication cannot be > eavesdropped" appears in all use cases so could be moved to section 4.1 > but I think it needs to be reworded in terms of the media always being > encrypted as I don't like the term "eavesdropped" which is not defined. > > > > Regards > > Andy > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Sun Jun 10 13:21:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4618F21F852B for ; Sun, 10 Jun 2012 13:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmCrFqHkStLt for ; Sun, 10 Jun 2012 13:21:19 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 819E221F8522 for ; Sun, 10 Jun 2012 13:21:19 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3734878lbb.31 for ; Sun, 10 Jun 2012 13:21:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=VeH05rZMILLckCHRN6rvkw/ijEMXdn8zlQTe9oJO83w=; b=DMLd4q5xPQ7Y41t44ZUNh63OyUTmiOJAf4S/Du+wHzDljTkBy02XivEJpln2gRzPrX r44qnvCkiirqMSKQMstfCVpHIxul9xKvw07yT1M2yIXkdbmQdPV1JQEHl6bBTm8SQCRK M73UOtCD7f8GPWiFfboX1je7sb6iBVbW1Phatn55hGnkOPHWed0wQDKFNDsfyfi0d/y0 tKDGMzDcCeyANOpjNBU0nzX2s7EmYNrmxFTm0TjhS53yHmYnG969eQtQQw8KzJj1xQyE ZnVP+dk+UiGqcCDZJlAB7wd5i/MkuMgOUyJ2lAHrGdAvVnjEE91XfjmpYSQx6Fv3Djbt 26rw== Received: by 10.112.24.194 with SMTP id w2mr2238025lbf.75.1339359678394; Sun, 10 Jun 2012 13:21:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Sun, 10 Jun 2012 13:20:58 -0700 (PDT) In-Reply-To: References: <4FCF0EAC.3040900@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 10 Jun 2012 22:20:58 +0200 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmfOtki/PRvW9LsIf/XbsoVgxmwO+ZSH2YkwSe5wU1tMFyDV82ZuoeRdnTStHMI6z6qDtrV Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN tests (ICE candidates) and VPN (session delayed) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 20:21:20 -0000 2012/6/10 Cullen Jennings : > I get that the VPN takes however long to timeout, but given that other ST= UN servers do respond, why are you dealing your whole WebRTC session waitin= g for that stun server. Just ignore it once you get some response from anot= her interface. That sounds simple and good :) Thanks. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Sun Jun 10 14:47:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80DA21F854B for ; Sun, 10 Jun 2012 14:47:05 -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=[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 p8bmKv9Yy5Gj for ; Sun, 10 Jun 2012 14:47:05 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C5A3021F8543 for ; Sun, 10 Jun 2012 14:47:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB6C339E106 for ; Sun, 10 Jun 2012 23:47:18 +0200 (CEST) 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 dZVbK2eAtbEy for ; Sun, 10 Jun 2012 23:47:17 +0200 (CEST) Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0A19639E056 for ; Sun, 10 Jun 2012 23:47:17 +0200 (CEST) Message-ID: <4FD515D4.3000908@alvestrand.no> Date: Sun, 10 Jun 2012 23:47:00 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120411 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <13D57612-5ADF-4B23-B7A4-81B212D49C66@iii.ca> In-Reply-To: <13D57612-5ADF-4B23-B7A4-81B212D49C66@iii.ca> Content-Type: multipart/alternative; boundary="------------090304060605000509070702" Subject: Re: [rtcweb] Reg retransmissions using JSEP approach. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 21:47:05 -0000 This is a multi-part message in MIME format. --------------090304060605000509070702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit An implementation of ROAP on top of JSEP (-00) is available here: http://code.google.com/p/webrtc-samples/source/browse/#svn%2Ftrunk%2Froap-jsep One of the areas in which it is incomplete is retransmissions.... On 06/10/2012 04:21 PM, Cullen Jennings wrote: > On Jun 9, 2012, at 7:26 , kiran kumar wrote: > >> Hi all, >> >> I am new to this list, so please don't mind if I am repeating the same question, if it has already discussed in this list. >> >> My doubt is regarding how JSEP style of implementation will differentiate the retransmission of messges with out ROAP. >> >> According to few mails and discussion lists, It is specified that ROAP is going to be replaced by JSEP. >> But in updated JSEP draft an example with ROAP is also provided. >> >> If ROAP is going to be replaced by JSEP, which part of JSEP will differentiate the retransmitted offers. >> ROAP is having "seq" field to differentiate it. >> Is that part going to be completely left to the application protocol ? >> > Yes, I think the idea i the application would have to deal with that. It probably needs to keep track of the keeping between the offer / answers to the seq number too so that if an offer is rejected and it rolls back to reg previous offer, it has that offer so it can roll back. At the same time browser implementation also need to keep track of the various offers so they can roll back. More text is needed in the drafts on all this. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090304060605000509070702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit An implementation of ROAP on top of JSEP (-00) is available here:

http://code.google.com/p/webrtc-samples/source/browse/#svn%2Ftrunk%2Froap-jsep

One of the areas in which it is incomplete is retransmissions....

On 06/10/2012 04:21 PM, Cullen Jennings wrote: 
On Jun 9, 2012, at 7:26 , kiran kumar wrote:


Hi all,
 
I am new to this list, so please don't mind if I am repeating the same question, if it has already discussed in this list.
 
My doubt is regarding how JSEP style of implementation will differentiate the retransmission of messges with out ROAP.
 
According to few mails and discussion lists, It is specified that ROAP is going to be replaced by JSEP.
But in updated JSEP draft an example with ROAP is also provided.
 
If ROAP is going to be replaced by JSEP, which part of JSEP will differentiate the retransmitted offers.
ROAP is having "seq" field to differentiate it.
Is that part going to be completely left to the application protocol ?
 

Yes, I think the idea i the application would have to deal with that. It probably needs to keep track of the keeping between the offer / answers to the seq number too so that if an offer is rejected and it rolls back to reg previous offer, it has that offer so it can roll back. At the same time browser implementation  also need to keep track of the various offers so they can roll back. More text is needed in the drafts on all this. 

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

--------------090304060605000509070702-- From harald@alvestrand.no Sun Jun 10 14:50:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE521F8552 for ; Sun, 10 Jun 2012 14:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2++v+UyJknMZ for ; Sun, 10 Jun 2012 14:50:46 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0661921F8550 for ; Sun, 10 Jun 2012 14:50:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 70E7639E106 for ; Sun, 10 Jun 2012 23:51:00 +0200 (CEST) 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 pCUJ0fi2gaFg for ; Sun, 10 Jun 2012 23:50:59 +0200 (CEST) Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A0B0A39E056 for ; Sun, 10 Jun 2012 23:50:59 +0200 (CEST) Message-ID: <4FD516B3.40501@alvestrand.no> Date: Sun, 10 Jun 2012 23:50:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120411 Thunderbird/11.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 21:50:47 -0000 On 06/10/2012 05:33 PM, Hutton, Andrew wrote: > Hi, > > Some comments on draft-ietf-rtcweb-use-cases-and-requirements-07. > > Section 4.1.1.1 (Simple Video Communication Service) contains the statement "Each user can also pause sending of media (audio, video, or both) and mute incoming media". I think this and the associated requirements need some clarification for example whether the requirement is to control the direction of the media and therefore requires the generation of a new SDP offer with for example a direction of "recvonly/inactive". The only associated requirement seems to be A8 but this does not help clarify what is meant by "pause" in the use case. It needs to be clarified whether the pause/resume/mute are actions within the browser or are actions which result in notifications to the remote user. > > Maybe we could add a use case which involves controlling the direction of multiple streams to emulate switching between different users in a multiparty call scenario. > > > The statement "It is essential that the communication cannot be eavesdropped" appears in all use cases so could be moved to section 4.1 but I think it needs to be reworded in terms of the media always being encrypted as I don't like the term "eavesdropped" which is not defined. If we want to define the term, we might want to use the term "wiretapping", and refer to RFC 2804 for the definition. (having been involved in that discussion, I've got some personal fondness for that definition...) > > Regards > Andy > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From g.kiranreddy4u@gmail.com Sun Jun 10 21:29:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE39621F84A6 for ; Sun, 10 Jun 2012 21:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baVPE7TVx-o3 for ; Sun, 10 Jun 2012 21:29:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 330CA21F8494 for ; Sun, 10 Jun 2012 21:29:57 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so8679442obb.31 for ; Sun, 10 Jun 2012 21:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F+ItfZ9b9tqKgwrl9ucokToom5VAgCE5TmzxT2HLrQQ=; b=UlLMnXD7Aj8xj6PI2Y084Fmxo+hI6CT3kMuEFmoh80HvDLdvYO8HbvorrCQbbFhJCG OVOyCFZ/ewAheoBPdNmBOKkwPFkWBx14c13mxGQhpppP2JRAYyY52kHgIX5G9KS9RbUk 7ZaAp0GZJILI4uKoiv0fk6LxZ7FUy2AaFdEqRRhygkWd3CPzkPHuKKQoMFMQeZaKglzc jwXiogv7mG28MNvXT8qwfksLs38lFA5lr0h79htKDkmCmUTS5+RxwbCwwYOU0r15X6No UILQKVnE6EBjuPq+6ElKhVGnlrgnPB3UT1JwySxwGu0jsg1x6BqGqi2rRsrPLb3GVv5a qEPA== Received: by 10.50.209.73 with SMTP id mk9mr5530063igc.66.1339388996662; Sun, 10 Jun 2012 21:29:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.135.5 with HTTP; Sun, 10 Jun 2012 21:29:36 -0700 (PDT) In-Reply-To: <13D57612-5ADF-4B23-B7A4-81B212D49C66@iii.ca> References: <13D57612-5ADF-4B23-B7A4-81B212D49C66@iii.ca> From: kiran kumar Date: Mon, 11 Jun 2012 09:59:36 +0530 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=14dae93407d75cb7c804c22acd1a Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reg retransmissions using JSEP approach. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 04:29:58 -0000 --14dae93407d75cb7c804c22acd1a Content-Type: text/plain; charset=ISO-8859-1 Thanks for your quick respnse, Thanks, Kiran. On Sun, Jun 10, 2012 at 7:51 PM, Cullen Jennings wrote: > > On Jun 9, 2012, at 7:26 , kiran kumar wrote: > > > Hi all, > > > > I am new to this list, so please don't mind if I am repeating the same > question, if it has already discussed in this list. > > > > My doubt is regarding how JSEP style of implementation will > differentiate the retransmission of messges with out ROAP. > > > > According to few mails and discussion lists, It is specified that ROAP > is going to be replaced by JSEP. > > But in updated JSEP draft an example with ROAP is also provided. > > > > If ROAP is going to be replaced by JSEP, which part of JSEP will > differentiate the retransmitted offers. > > ROAP is having "seq" field to differentiate it. > > Is that part going to be completely left to the application protocol ? > > > > Yes, I think the idea i the application would have to deal with that. It > probably needs to keep track of the keeping between the offer / answers to > the seq number too so that if an offer is rejected and it rolls back to reg > previous offer, it has that offer so it can roll back. At the same time > browser implementation also need to keep track of the various offers so > they can roll back. More text is needed in the drafts on all this. > > --14dae93407d75cb7c804c22acd1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for your quick respnse,
=A0
Thanks,
Kiran.

On Sun, Jun 10, 2012 at 7:51 PM, Cullen Jennings= <f= luffy@iii.ca> wrote:

On Jun 9, 2012, at 7:26 , kiran kumar wrote:

&= gt; Hi all,
>
> I am new to this list, so please don't mind= if I am repeating the same question, if it has already discussed in this l= ist.
>
> My doubt is regarding how JSEP style of implementation will di= fferentiate the retransmission of messges with out ROAP.
>
> Ac= cording to few mails and discussion lists, It is specified that ROAP is goi= ng to be replaced by JSEP.
> But in updated JSEP draft an example with ROAP is also provided.
&g= t;
> If ROAP is going to be replaced by JSEP, which part of JSEP will= differentiate the retransmitted offers.
> ROAP is having "seq&q= uot; field to differentiate it.
> Is that part going to be completely left to the application protocol ?=
>

Yes, I think the idea i the application would h= ave to deal with that. It probably needs to keep track of the keeping betwe= en the offer / answers to the seq number too so that if an offer is rejecte= d and it rolls back to reg previous offer, it has that offer so it can roll= back. At the same time browser implementation =A0also need to keep track o= f the various offers so they can roll back. More text is needed in the draf= ts on all this.


--14dae93407d75cb7c804c22acd1a-- From g.kiranreddy4u@gmail.com Sun Jun 10 21:30:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A4821F84D9 for ; Sun, 10 Jun 2012 21:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DxIJYTHnOuN for ; Sun, 10 Jun 2012 21:30:20 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F218021F84A6 for ; Sun, 10 Jun 2012 21:30:19 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2578616ghb.31 for ; Sun, 10 Jun 2012 21:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4KnH+Y5MmmFRG/kqVt6kEQLwcpqXMO3Ot8zN5Ta+3sk=; b=r+pyd2Oy9LDdX4Zw9Lu6w/6GGvpUcLqdpDNFg/cAn6DCa+Njvan4e4y5GoNBGFSrSF PRvGZ88TBOMIr2emj9iPr1DNh6ck9zUo8ks0rOZtXvmw1DOVFQObuxYn2tEXv5eHtWyW Sr0E/nAiX1W5J9Z9uaqoQ2j+pNJzXln9GrnnX7VOpQbh3uvHZeOy0+oK0GvZck2MFR85 FHo/I+LzkyyOqCClgGZdJvC14IY3N0J22LHDtXXf1vRzQHV8g3DW9ifqCOjoKAJ+Iwbl GnWH+LSDc3valM06nuaGDpx+EVKUDbTTLocEZmf7WKIAWfxs3obPm/dp/obWhclJKIlV cOkA== Received: by 10.50.161.234 with SMTP id xv10mr5534222igb.66.1339389019415; Sun, 10 Jun 2012 21:30:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.135.5 with HTTP; Sun, 10 Jun 2012 21:29:59 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16046E98@inba-mail02.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C16046E98@inba-mail02.sonusnet.com> From: kiran kumar Date: Mon, 11 Jun 2012 09:59:59 +0530 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=14dae93410c3b7e3cb04c22aced9 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Reg retransmissions using JSEP approach. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 04:30:20 -0000 --14dae93410c3b7e3cb04c22aced9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for your quick response, Thanks, Kiran. On Sun, Jun 10, 2012 at 12:04 AM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Kiran,**** > > ** ** > > As per JSEP, it is left to the application protocol. The application > protocol shall have =93seq=94 field equivalent to differentiate the > retransmitted offers.**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *kiran kumar > *Sent:* Saturday, June 09, 2012 4:56 PM > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Reg retransmissions using JSEP approach.**** > > ** ** > > Hi all,**** > > **** > > I am new to this list, so please don't mind if I am repeating the same > question, if it has already discussed in this list.**** > > **** > > My doubt is regarding how JSEP style of implementation will differentiate > the retransmission of messges with out ROAP.**** > > **** > > According to few mails and discussion lists, It is specified that ROAP is > going to be replaced by JSEP.**** > > But in updated JSEP draft an example with ROAP is also provided.**** > > **** > > If ROAP is going to be replaced by JSEP, which part of JSEP will > differentiate the retransmitted offers.**** > > ROAP is having "seq" field to differentiate it.**** > > Is that part going to be completely left to the application protocol ?***= * > > **** > > **** > > Thanks,**** > > Kiran.**** > > **** > --14dae93410c3b7e3cb04c22aced9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks for your quick response,
=A0
Thanks,
Kiran.

On Sun, Jun 10, 2012 at 12:04 AM, Ravindran, Par= thasarathi <pravindran@sonusnet.com> wrote:

Hi Kiran,<= /p>

=A0

As per JSEP, it is left to the = application protocol. The application protocol shall have =93seq=94 field e= quivalent to differentiate the retransmitted offers.

=A0

Thanks

Partha

=A0

From: rtcweb-bounces@ietf.org [mailt= o:rtcweb-bounc= es@ietf.org] On Behalf Of kiran kumar
Sent: Saturday, June 09, 2012 4:56 PM
To: rtcweb@ietf.org
Subject:= [rtcweb] Reg retransmissions using JSEP approach.

=A0

Hi all,

=A0

I am new to this list, so please don't mind if I= am repeating the same question, if it has already discussed in this list.<= u>

=A0

My doubt is regarding how JSEP style of implementati= on will differentiate the retransmission of messges with out ROAP.

=A0

According to few mails and discussion lists, It is s= pecified that=A0ROAP is going to be replaced by JSEP.

But in updated JSEP draft an example with ROAP is al= so provided.

=A0

If=A0ROAP is going to be replaced by JSEP, which par= t of JSEP will differentiate the retransmitted offers.

ROAP is having "seq" field to differentiat= e it.

Is that part going to be completely left to the appl= ication protocol ?

=A0

=A0

Thanks,

Kiran.

=A0

<= /div>

--14dae93410c3b7e3cb04c22aced9-- From magnus.westerlund@ericsson.com Mon Jun 11 07:11:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9121F85C2 for ; Mon, 11 Jun 2012 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 sRamHIQQICWW for ; Mon, 11 Jun 2012 07:11:49 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3F11021F85C6 for ; Mon, 11 Jun 2012 07:11:49 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-17-4fd5fca39282 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B9.52.28636.3ACF5DF4; Mon, 11 Jun 2012 16:11:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Mon, 11 Jun 2012 16:11:45 +0200 Message-ID: <4FD5FC9F.1030401@ericsson.com> Date: Mon, 11 Jun 2012 16:11:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvre6SP1f9DWZ8ZbVY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGW9797AUXGetuLjzGEsD432WLkZODgkBE4lXnycwQdhiEhfu rWfrYuTiEBI4xSix8/kkdpCEkMByRon1DTwgNq+AtsSh/XfYQGwWAVWJtlt/mUFsNgELiZs/ GsHiogLBEi/2XGGFqBeUODnzCdgyEQF1icsPL4DNFAbq3dvzgxlisaTEvfbVYL3MAnoSU662 MELY8hLNW2czQ9ygLdHQ1ME6gZF/FpKxs5C0zELSsoCReRWjcG5iZk56uaFealFmcnFxfp5e ceomRmCYHdzyW3cH46lzIocYpTlYlMR5uZL2+wsJpCeWpGanphakFsUXleakFh9iZOLglGpg 1JbYvy97U5PBHgvR9QmZj4tnx7Yrul9PyBScZXRshbruhsM+zwo2PJysd1frWNCr9n2sP9tm MS/oa2EVW1OQUHi9IPKT2OK1rCc73Ut97Zc4PhP05Ge4p1QxYZ7672vbenft6yo+XlGlpvnX iOUBm2SzppK8oDlTvf2524erc7KqJrycdPaHEktxRqKhFnNRcSIAQa5OKwECAAA= Subject: [rtcweb] Remote Participation details X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:11:54 -0000 WG, For tomorrows interim meeting the WIKI now contains some information about how to participate remotely, there is two options: http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart If you have any questions please contact the chairs. 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 ekr@rtfm.com Tue Jun 12 01:33:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E37B21F84E6 for ; Tue, 12 Jun 2012 01:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 vMRLjZ65xWQX for ; Tue, 12 Jun 2012 01:33:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7C521F85B1 for ; Tue, 12 Jun 2012 01:33:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3230327vbb.31 for ; Tue, 12 Jun 2012 01:33:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=Fl6D5P3LSLiVxSAVKPDME/RAtIi7HhkKCIq9bzNeXNU=; b=PnpD/h8dqpO0YB0XEwzrEy4YWIbtiGJdgnYzWEGWDfTmB3wowK9uGWlRSzSvIVUhU3 py82LKaZYRTT2Ij9537IV/tgk73evJz/WLW8l2PYcUAGY3ktZDAimP92NGYwfcoeP5X/ gyxV3vZbl8ygFfyipbr0j9k4ImPALd111XbRVddZPSPScXZj/7JvivG51cQJsZk0PGbJ ZgA+jdq2dFl1NIWyY/l+qDHSQOm3N5fJ2MCFkFBOidGBOhohiNzhyI4eICgqFhLjEToy tmSyii/W+gy9+Yo3TecoetBwUsneaPDcJrzpU9lwSexxpMqQtjXMKUYfQPvNNyVCCU8H I9UA== Received: by 10.52.88.176 with SMTP id bh16mr11663665vdb.132.1339490000919; Tue, 12 Jun 2012 01:33:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Tue, 12 Jun 2012 01:32:40 -0700 (PDT) X-Originating-IP: [216.239.55.84] From: Eric Rescorla Date: Tue, 12 Jun 2012 01:32:40 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnaXfthcV3PN4huytvnFfoqTNomUtSoK+PHXegLET5YIbAa0cPzxUq6XudgAZybozXp6rvv Subject: [rtcweb] What I think we need to do about ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 08:33:22 -0000 To recap what I was saying on the list: 1. Some method of determining when a candidate pair has failed. 2. Some method of failing over to another candidate pair after failure in as clean a fashion as possible, preferably exploiting the fact that we already know about other valid candidate pairs, if possible. Example: I had a direct and relayed pair that worked and I chose direct. Is there a way to fall back to relayed without doing a total re-ice. 3. When I discover a new candidate pair, some way of investigating it and maybe changing to it w/o interfering with my current active candidate pair. I think we need to do (1) and probably (2) now and (3) is a nice to have. -Ekr From bernard_aboba@hotmail.com Tue Jun 12 01:53:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CB521F8595 for ; Tue, 12 Jun 2012 01:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.344 X-Spam-Level: X-Spam-Status: No, score=-99.344 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 k9uaCileb4g3 for ; Tue, 12 Jun 2012 01:53:34 -0700 (PDT) Received: from bay0-omc3-s5.bay0.hotmail.com (bay0-omc3-s5.bay0.hotmail.com [65.54.190.143]) by ietfa.amsl.com (Postfix) with ESMTP id A001221F8589 for ; Tue, 12 Jun 2012 01:53:32 -0700 (PDT) Received: from BAY0-P4-EAS75 ([65.54.190.189]) by bay0-omc3-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 01:53:31 -0700 X-Originating-IP: [24.16.96.166] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: Date: Tue, 12 Jun 2012 01:53:29 -0700 To: Eric Rescorla MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 12 Jun 2012 08:53:31.0926 (UTC) FILETIME=[D7E90360:01CD4878] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What I think we need to do about ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 08:53:36 -0000 Issue 1 is addressed via continuing consent, no?=20 WRT 2, ICE prioritizes pairs so there are shortcuts that can be taken, depen= ding on what you know. If an interface is down, no need to try those host ca= ndidates. Similarly, no need to retry pairs that just failed. The question w= ith relay fail back is whether the allocation is still valid. 3. It seems sensible to be able to cache recent tests and not rerun them. If= that were done then full offer/answers might only generate delta tests. On Jun 12, 2012, at 1:33 AM, "Eric Rescorla" wrote: > To recap what I was saying on the list: >=20 > 1. Some method of determining when a candidate pair has failed. >=20 > 2. Some method of failing over to another candidate pair after > failure in as clean a fashion as possible, preferably exploiting > the fact that we already know about other valid candidate pairs, > if possible. Example: I had a direct and relayed pair that worked > and I chose direct. Is there a way to fall back to relayed without > doing a total re-ice. >=20 > 3. When I discover a new candidate pair, some way of investigating > it and maybe changing to it w/o interfering with my current active > candidate pair. >=20 > I think we need to do (1) and probably (2) now and (3) is a nice to have. >=20 > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From michawe@ifi.uio.no Tue Jun 12 02:06:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6163921F8517 for ; Tue, 12 Jun 2012 02:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2SlruwrAAt8 for ; Tue, 12 Jun 2012 02:06:38 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90C21F8542 for ; Tue, 12 Jun 2012 02:06:38 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1SeN3d-0000G0-5E for rtcweb@ietf.org; Tue, 12 Jun 2012 11:06:37 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtp (Exim 4.76) (envelope-from ) id 1SeN3c-0003qN-Py for rtcweb@ietf.org; Tue, 12 Jun 2012 11:06:37 +0200 Message-ID: <4FD7069C.8080803@ifi.uio.no> Date: Tue, 12 Jun 2012 11:06:36 +0200 From: Michael Welzl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 2 total rcpts 20564 max rcpts/h 45 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 403674E9237EFDA5DDE14FCB1ACBA266E9B4F773 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 8600 max/h 20 blacklist 0 greylist 0 ratelimit 0 Subject: [rtcweb] Question about usage of data traffic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 09:06:39 -0000 Hi, Sorry if I'm asking a dummy question... I'm still somewhat new to rtcweb, and certainly quite new to this list: It seems that the group's idea of data traffic is that this would be latency-critical traffic, possibly combined with other real-time communication. Slide 2 of the slideset at http://trac.tools.ietf.org/wg/rtcweb/trac/attachment/wiki/WikiStart/Non-Media%20Data%20in%20RTCWEB.ppt says: Use cases: -Dynamic meta data for Conference and other real-time services -Gaming data with low latency requirements -Others? This makes me wonder: once we have rtcweb in place, what stops a web site developer from just providing a web-based file transfer service between browsers? And: if that's a possibility, would we even want to prevent that? (I'd say no) Similarly, I can pull files on my Skype to send e.g. photographs to a person I'm chatting with. I'd imagine that this sort of thing would also be attractive for rtcweb based applications, and I don't see a reason to prevent this. What's different here is that we're in these cases dealing with greedy, non-latency-critical traffic, and possibly lots of it. Could this even be a new use case? Cheers, Michael From tterriberry@mozilla.com Tue Jun 12 02:11:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B88B21F85C4 for ; Tue, 12 Jun 2012 02:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kBHVg4CnFSM for ; Tue, 12 Jun 2012 02:11:14 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4C56221F85A3 for ; Tue, 12 Jun 2012 02:11:11 -0700 (PDT) Received: from [10.59.1.63] (18.225.181.62.in-addr.dgcsystems.net [62.181.225.18]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B5817F21F6 for ; Tue, 12 Jun 2012 02:11:10 -0700 (PDT) Message-ID: <4FD707AD.1040601@mozilla.com> Date: Tue, 12 Jun 2012 02:11:09 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD7069C.8080803@ifi.uio.no> In-Reply-To: <4FD7069C.8080803@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Question about usage of data traffic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 09:11:15 -0000 Michael Welzl wrote: > What's different here is that we're in these cases dealing with greedy, > non-latency-critical traffic, and possibly lots of it. Could this even > be a new use case? There is currently a "Simple Video Communication Service with file exchange" use case (see Section 4.2.8 in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-08). Are there additional derived requirements that are needed to support this use case? From randell-ietf@jesup.org Tue Jun 12 02:20:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7C921F85DA for ; Tue, 12 Jun 2012 02:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXUYovwPH67Z for ; Tue, 12 Jun 2012 02:20:51 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 48A3D21F8505 for ; Tue, 12 Jun 2012 02:20:50 -0700 (PDT) Received: from [216.239.55.84] (helo=[192.168.146.122]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SeNHN-0003HB-4m for rtcweb@ietf.org; Tue, 12 Jun 2012 04:20:49 -0500 Message-ID: <4FD709EF.7030001@jesup.org> Date: Tue, 12 Jun 2012 05:20:47 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD7069C.8080803@ifi.uio.no> In-Reply-To: <4FD7069C.8080803@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Question about usage of data traffic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 09:20:55 -0000 On 6/12/2012 5:06 AM, Michael Welzl wrote: > This makes me wonder: once we have rtcweb in place, what stops a web > site developer from just providing a web-based file transfer service > between browsers? And: if that's a possibility, would we even want to > prevent that? (I'd say no) > > Similarly, I can pull files on my Skype to send e.g. photographs to a > person I'm chatting with. I'd imagine that this sort of thing would also > be attractive for rtcweb based applications, and I don't see a reason to > prevent this. Correct, support for this is a design goal. > What's different here is that we're in these cases dealing with greedy, > non-latency-critical traffic, and possibly lots of it. Could this even > be a new use case? This is the reason for the priority fields for the DataChannel objects, to allow the application to set the relative priorities of media channels and data. By default, we don't want data channels to starve media, but to take a share, so are reasonable for "look at this picture" cases. Large i-don'tcare-when transfers should be given somewhat lower priorities, real (low-bandwidth) realtime data should be given higher. -- Randell Jesup randell-ietf@jesup.org From michawe@ifi.uio.no Tue Jun 12 02:38:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115F721F8573 for ; Tue, 12 Jun 2012 02:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIN+2rlCGqT2 for ; Tue, 12 Jun 2012 02:38:40 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 436A621F8466 for ; Tue, 12 Jun 2012 02:38:39 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1SeNYc-0000o3-LS for rtcweb@ietf.org; Tue, 12 Jun 2012 11:38:38 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtp (Exim 4.76) (envelope-from ) id 1SeNYc-0002YR-8d for rtcweb@ietf.org; Tue, 12 Jun 2012 11:38:38 +0200 Message-ID: <4FD70E1D.10509@ifi.uio.no> Date: Tue, 12 Jun 2012 11:38:37 +0200 From: Michael Welzl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD7069C.8080803@ifi.uio.no> <4FD707AD.1040601@mozilla.com> In-Reply-To: <4FD707AD.1040601@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 3 sum msgs/h 3 total rcpts 20565 max rcpts/h 45 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D503BFA060CD48FD035BA860A5A3CEAA4765F55C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 8601 max/h 20 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [rtcweb] Question about usage of data traffic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 09:38:41 -0000 On 6/12/12 11:11 AM, Timothy B. Terriberry wrote: > Michael Welzl wrote: >> What's different here is that we're in these cases dealing with greedy, >> non-latency-critical traffic, and possibly lots of it. Could this even >> be a new use case? > > There is currently a "Simple Video Communication Service with file > exchange" use case (see Section 4.2.8 in > http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-08). > Are there additional derived requirements that are needed to support > this use case? First: very sorry for missing this one! I looked at this very draft again just yesterday, but somehow didn't notice the file transfer bit. On a side note, when looking through the requirements derived from this use case now, I got the impression that it would have been more reader-friendly to write: "In addition to the Simple Video Communication Service use-case, this use-case has the following requirements:" and list just the new ones. Second: I don't think that there are additional requirements derived from that, but it can have architectural implications. (i.e. what is derived is, perhaps, a new property). => "file transfer" should then be a part of the use cases on the list in the slide set I mentioned. (I'm saying that because the slide asks: "others?") Given that file transfers are "part of the plan", I just think it's important for all of us to understand that there may be a lot of data traffic too (instead of pictures, people may be sending a movie... or you could even have a website offering *nothing but* a file transfer service?! I have a feeling that this could even turn into an unintended "killer app" for rtcweb :-) ). Cheers, Michael From michawe@ifi.uio.no Tue Jun 12 02:39:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23F721F8597 for ; Tue, 12 Jun 2012 02:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbAzu864V0VS for ; Tue, 12 Jun 2012 02:39:26 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 3861D21F858D for ; Tue, 12 Jun 2012 02:39:26 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1SeNZN-0000vW-I8 for rtcweb@ietf.org; Tue, 12 Jun 2012 11:39:25 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtp (Exim 4.76) (envelope-from ) id 1SeNZN-0005aB-6K for rtcweb@ietf.org; Tue, 12 Jun 2012 11:39:25 +0200 Message-ID: <4FD70E4D.7010300@ifi.uio.no> Date: Tue, 12 Jun 2012 11:39:25 +0200 From: Michael Welzl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD7069C.8080803@ifi.uio.no> <4FD709EF.7030001@jesup.org> In-Reply-To: <4FD709EF.7030001@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 3 sum rcpts/h 4 sum msgs/h 4 total rcpts 20566 max rcpts/h 45 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C35CF2377F5AC528AD8708145FA6F6A3B9ABE8E4 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 8602 max/h 20 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [rtcweb] Question about usage of data traffic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 09:39:26 -0000 On 6/12/12 11:20 AM, Randell Jesup wrote: > On 6/12/2012 5:06 AM, Michael Welzl wrote: > >> This makes me wonder: once we have rtcweb in place, what stops a web >> site developer from just providing a web-based file transfer service >> between browsers? And: if that's a possibility, would we even want to >> prevent that? (I'd say no) >> >> Similarly, I can pull files on my Skype to send e.g. photographs to a >> person I'm chatting with. I'd imagine that this sort of thing would also >> be attractive for rtcweb based applications, and I don't see a reason to >> prevent this. > > Correct, support for this is a design goal. > >> What's different here is that we're in these cases dealing with greedy, >> non-latency-critical traffic, and possibly lots of it. Could this even >> be a new use case? > > This is the reason for the priority fields for the DataChannel > objects, to allow the application to set the relative priorities of > media channels and data. By default, we don't want data channels to > starve media, but to take a share, so are reasonable for "look at this > picture" cases. Large i-don'tcare-when transfers should be given > somewhat lower priorities, real (low-bandwidth) realtime data should > be given higher. > I see; thanks. Sounds good to me. Cheers, Michael From harald@alvestrand.no Tue Jun 12 03:14:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B9021F8546 for ; Tue, 12 Jun 2012 03:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.799 X-Spam-Level: X-Spam-Status: No, score=-108.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 5xN7VwKfXte0 for ; Tue, 12 Jun 2012 03:14:09 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFDA21F848F for ; Tue, 12 Jun 2012 03:14:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C543B39E13B for ; Tue, 12 Jun 2012 12:14:26 +0200 (CEST) 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 5JyL9T3V4kEJ for ; Tue, 12 Jun 2012 12:14:26 +0200 (CEST) Received: from [10.59.1.65] (18.225.181.62.in-addr.dgcsystems.net [62.181.225.18]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0D39939E062 for ; Tue, 12 Jun 2012 12:14:26 +0200 (CEST) Message-ID: <4FD71670.9050900@alvestrand.no> Date: Tue, 12 Jun 2012 12:14:08 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] CNAME as a media stream identifier - what I don't think works X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 10:14:10 -0000 OK, from the debate today it's clear that the picture is not clear in everyone's minds.... with the API that the WG currently has defined, the following is a legal set of calls. So any spec needs to be able to describe the result - even if it is an error event at some point. (Never mind if it is a *wise* set of calls.) pc = new PeerConnection(); GetUserMedia(..., function(stream) { stream1 = stream; stream2 = new MediaStream(stream1.audioTracks, stream1.videoTracks); } ..... stuff to start connecting .... pc.addStream(stream1); pc.addStream(stream2); offer = pc.createOffer(....); With MSID, the offer will look like this: .... m=audio a=ssrc:1234 msid=xyzzy a0 a=ssrc:1234 msid=xyww a0 ... m=video a=ssrc:1256 msid=xyzzy v0 a=ssrc:1256 msid=xyww v0 and the expectation on the recipient side is that you will get pc.onaddstream called with: 1) stream with id = xyzzy, audio and video 2) stream with id = xyww, audio and video Cullen, this is for you: If a mediastream is identified by CNAME, what do you expect to have happen? Harald From juberti@google.com Tue Jun 12 04:36:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A9C21F866B for ; Tue, 12 Jun 2012 04:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 ADTcFxN1uytG for ; Tue, 12 Jun 2012 04:36:57 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1AA21F8663 for ; Tue, 12 Jun 2012 04:36:57 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3867820ggn.31 for ; Tue, 12 Jun 2012 04:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=HWPwYEVN1sgQUtijLB/nBEjycWvTaxTWC/PneGG2VlY=; b=Hx5gMM97CDWAtOb7shdrcLRMrSekT2kMr2+mRtU1VYOqYNmAWariDWr/vVM+oOJeds Qkrous47dyZWn57/uiooVvmuzCN2SWYHs2tzSGNnyEnKON/ynxfiXiz7rjWPkUdbO+S/ jHP9LH0i3TaZMB3CzdWiCpDHyQ51g5D2YFsWvxRbLWdv71wCQ3/o0V2LYssTfeL+rzFE 50Ed/aTDIML8gv5I1z9wRBl1xzWyv+2aQD3dlVQjN7qs4DhVuOWMGxbV+6HfQPSEWqDi MJyv6I9yO3e1o5Y4aHyHRrnyvsikgkiDL7LvzSgraTBK0ft7DLfov6WtfyUV1NG9gn8P NBWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=HWPwYEVN1sgQUtijLB/nBEjycWvTaxTWC/PneGG2VlY=; b=TbtFN3iVeJOqlp71tzVkVxzyozeantOKmO6Sio4OuqZtfnAOnd4bxc6N/czQpwGgx5 5dQAOXDIEJ9LK9PdYS3b2FkOTLI+0lQOZoA4xl9J+9fJ+mlofIs3KgUkexfiHVXRexMJ nXvOhtRwFtS5ZmGEwyyG4UZYuSVd4J1r/oSj5kV6ZDkJ2HxBElrtcPRIC85Yvg4e3J9Z /kC4Vbyu5Fpc6ASKWPpX650bKSy0x8A+VIuYcDgcSI03sAThucS+JGMAbmSJGMGoX3YN DVTnbzm91ae5l/GTz6mzLuJ4Ck/1jzNBSOKn1O4kiqneugq7qK/gjHIlzUCTdvvWcjQk j87Q== Received: by 10.50.179.105 with SMTP id df9mr8121920igc.4.1339501016787; Tue, 12 Jun 2012 04:36:56 -0700 (PDT) Received: by 10.50.179.105 with SMTP id df9mr8121914igc.4.1339501016683; Tue, 12 Jun 2012 04:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.218 with HTTP; Tue, 12 Jun 2012 04:36:36 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 12 Jun 2012 07:36:36 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=14dae934128946961a04c244e2bc X-System-Of-Record: true X-Gm-Message-State: ALoCoQk6T3JhuF0Wi8sbr6ro3KNO2oDfrettLm8ud461cqFA7ssT96C4bwxE9m+ESucIoFQag4HzvtZjNkhSZExggSFKXhDtvUbj1QrbEgqSiJ7Vq/znRE9lWJFduLhWURQpIs/oC1MJ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What I think we need to do about ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:36:58 -0000 --14dae934128946961a04c244e2bc Content-Type: text/plain; charset=UTF-8 On Tue, Jun 12, 2012 at 4:53 AM, Bernard Aboba wrote: > Issue 1 is addressed via continuing consent, no? > Is this frequent enough? We probably need to be able to detect failures in ~5 seconds or so. > > WRT 2, ICE prioritizes pairs so there are shortcuts that can be taken, > depending on what you know. If an interface is down, no need to try those > host candidates. Similarly, no need to retry pairs that just failed. The > question with relay fail back is whether the allocation is still valid. > How does this work at the wire level? Is this a new USE-CANDIDATE ping on the new pair from the controlling side? > > 3. It seems sensible to be able to cache recent tests and not rerun them. > If that were done then full offer/answers might only generate delta tests. > This assumes that both sides are keeping all unused candidates alive during the session. > > > > On Jun 12, 2012, at 1:33 AM, "Eric Rescorla" wrote: > > > To recap what I was saying on the list: > > > > 1. Some method of determining when a candidate pair has failed. > > > > 2. Some method of failing over to another candidate pair after > > failure in as clean a fashion as possible, preferably exploiting > > the fact that we already know about other valid candidate pairs, > > if possible. Example: I had a direct and relayed pair that worked > > and I chose direct. Is there a way to fall back to relayed without > > doing a total re-ice. > > > > 3. When I discover a new candidate pair, some way of investigating > > it and maybe changing to it w/o interfering with my current active > > candidate pair. > > > > I think we need to do (1) and probably (2) now and (3) is a nice to have. > > > > -Ekr > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --14dae934128946961a04c244e2bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 12, 2012 at 4:53 AM, Bernard= Aboba <bernard_aboba@hotmail.com> wrote:
Issue 1 is addressed via continuing consent, no?

<= /div>
Is this frequent enough? We probably need to be able to detect fa= ilures in ~5 seconds or so.=C2=A0

WRT 2, ICE prioritizes pairs so there are shortcuts that can be taken, depe= nding on what you know. If an interface is down, no need to try those host = candidates. Similarly, no need to retry pairs that just failed. The questio= n with relay fail back is whether the allocation is still valid.

How does this work at the wire level? Is t= his a new USE-CANDIDATE ping on the new pair from the controlling side?

3. It seems sensible to be able to cache recent tests and not rerun them. I= f that were done then full offer/answers might only generate delta tests.

This assumes that both sides are keeping= all unused candidates alive during the session.=C2=A0



On Jun 12, 2012, at 1:33 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:

> To recap what I was saying on the list:
>
> 1. Some method of determining when a candidate pair has failed.
>
> 2. Some method of failing over to another candidate pair after
> failure in as clean a fashion as possible, preferably exploiting
> the fact that we already know about other valid candidate pairs,
> if possible. Example: I had a direct and relayed pair that worked
> and I chose direct. Is there a way to fall back to relayed without
> doing a total re-ice.
>
> 3. When I discover a new candidate pair, some way of investigating
> it and maybe changing to it w/o interfering with my current active
> candidate pair.
>
> I think we need to do (1) and probably (2) now and (3) is a nice to ha= ve.
>
> -Ekr
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--14dae934128946961a04c244e2bc-- From bernard_aboba@hotmail.com Tue Jun 12 06:57:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2E21F85AC for ; Tue, 12 Jun 2012 06:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.971 X-Spam-Level: X-Spam-Status: No, score=-100.971 tagged_above=-999 required=5 tests=[AWL=1.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dveTIQ4-bVde for ; Tue, 12 Jun 2012 06:57:17 -0700 (PDT) Received: from blu0-omc1-s2.blu0.hotmail.com (blu0-omc1-s2.blu0.hotmail.com [65.55.116.13]) by ietfa.amsl.com (Postfix) with ESMTP id 952DC21F859A for ; Tue, 12 Jun 2012 06:57:17 -0700 (PDT) Received: from BLU169-W69 ([65.55.116.7]) by blu0-omc1-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 06:57:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3fab5f75-485c-42b1-8577-2bcbdce88620_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Date: Tue, 12 Jun 2012 06:57:16 -0700 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2012 13:57:17.0472 (UTC) FILETIME=[472EA200:01CD48A3] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What I think we need to do about ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 13:57:18 -0000 --_3fab5f75-485c-42b1-8577-2bcbdce88620_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Justin said: On Tue=2C Jun 12=2C 2012 at 4:53 AM=2C Bernard Aboba wrote: Issue 1 is addressed via continuing consent=2C no? Is this frequent enough? We probably need to be able to detect failures in = ~5 seconds or so.=20 [BA] Depends on the kind of failure. Removal/addition of an interface can = be detected very quickly (e.g. RFC 4436 can run in 5 ms). Detection of a f= ailure in the middle of the network will take longer=3B route flaps can cau= se transient loss=2C but often resolve themselves quickly (under 30 seconds= ) so switch in less than 15 seconds will risk false positives.=20 WRT 2=2C ICE prioritizes pairs so there are shortcuts that can be taken=2C = depending on what you know. If an interface is down=2C no need to try those= host candidates. Similarly=2C no need to retry pairs that just failed. The= question with relay fail back is whether the allocation is still valid. How does this work at the wire level? Is this a new USE-CANDIDATE ping on t= he new pair from the controlling side? [BA] In the event of a failure=2C it would make sense to be aggressive to r= estore media quickly. If you have a working pair=2C but are just looking fo= r a better one=2C you might not want to set flags until you've confirmed th= at the pair is actually better.=20 3. It seems sensible to be able to cache recent tests and not rerun them. I= f that were done then full offer/answers might only generate delta tests. This assumes that both sides are keeping all unused candidates alive during= the session.=20 [BA] I doubt that implementations would keep relay candidates alive if they= weren't chosen. But one could cache the list of candidates from both side= s minus the relays=2C update the host and server reflexive candidates and = prioritize pairs.=20 The question is whether you could skip any tests. If a pair has been recent= ly demonstrated to be working (e.g. it is working currently=2C but you've g= otten new pairs) you can skip the test. Similarly=2C if it's been marked a= s down.=20 =20 On Jun 12=2C 2012=2C at 1:33 AM=2C "Eric Rescorla" wrote: > To recap what I was saying on the list: > > 1. Some method of determining when a candidate pair has failed. > > 2. Some method of failing over to another candidate pair after > failure in as clean a fashion as possible=2C preferably exploiting > the fact that we already know about other valid candidate pairs=2C > if possible. Example: I had a direct and relayed pair that worked > and I chose direct. Is there a way to fall back to relayed without > doing a total re-ice. > > 3. When I discover a new candidate pair=2C some way of investigating > it and maybe changing to it w/o interfering with my current active > candidate pair. > > I think we need to do (1) and probably (2) now and (3) is a nice to have. > > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb = --_3fab5f75-485c-42b1-8577-2bcbdce88620_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Justin said:

On Tue=2C Jun 12=2C = 2012 at 4:53 AM=2C Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3B wrote= :
Issue 1 is addressed via continuing consent=2C no?
Is this frequent enough? We probably need to be able to detect = failures in ~5 seconds or so.

[BA] Depends on the kind of failure.&= nbsp=3B Removal/addition of an interface can be detected very quickly (e.g.= RFC 4436 can run in 5 ms). =3B Detection of a failure in the middle of= the network will take longer=3B route flaps can cause transient loss=2C bu= t often resolve themselves quickly (under 30 seconds) so switch in less tha= n 15 seconds will risk false positives.

WRT 2=2C ICE prioritizes pairs so there are shortcuts that can be taken=2C = depending on what you know. If an interface is down=2C no need to try those= host candidates. Similarly=2C no need to retry pairs that just failed. The= question with relay fail back is whether the allocation is still valid.

How does this work at the wire level? Is t= his a new USE-CANDIDATE ping on the new pair from the controlling side?
=
[BA] In the event of a failure=2C it would make sense to be aggressive = to restore media quickly. If you have a working pair=2C but are just lookin= g for a better one=2C you might not want to set flags until you've confirme= d that the pair is actually better.


3. It seems sensible to be able to cache recent tests and not rerun them. I= f that were done then full offer/answers might only generate delta tests.

This assumes that both sides are keeping= all unused candidates alive during the session.

[BA] I doubt that = implementations would keep relay candidates alive if they weren't chosen.&n= bsp=3B But one could cache the list of candidates from both sides minus the= relays=2C update the host =3B and server reflexive candidates and prio= ritize pairs.
The question is whether you could skip any tests. If a pa= ir has been recently demonstrated to be working (e.g. it is working current= ly=2C but you've gotten new pairs) you can skip the test. =3B Similarly= =2C if it's been marked as down.

 =3B



On Jun 12=2C 2012=2C at 1:33 AM=2C "Eric Rescorla" <=3Bekr@rtfm.com>=3B wrote:

>=3B To recap what I was saying on the list:
>=3B
>=3B 1. Some method of determining when a candidate pair has failed.
>=3B
>=3B 2. Some method of failing over to another candidate pair after
>=3B failure in as clean a fashion as possible=2C preferably exploiting >=3B the fact that we already know about other valid candidate pairs=2C >=3B if possible. Example: I had a direct and relayed pair that worked >=3B and I chose direct. Is there a way to fall back to relayed without >=3B doing a total re-ice.
>=3B
>=3B 3. When I discover a new candidate pair=2C some way of investigating=
>=3B it and maybe changing to it w/o interfering with my current active >=3B candidate pair.
>=3B
>=3B I think we need to do (1) and probably (2) now and (3) is a nice to = have.
>=3B
>=3B -Ekr
>=3B _______________________________________________
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

= --_3fab5f75-485c-42b1-8577-2bcbdce88620_-- From juberti@google.com Tue Jun 12 07:55:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D6721F86C3 for ; Tue, 12 Jun 2012 07:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 fc6EJn92viz0 for ; Tue, 12 Jun 2012 07:55:54 -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 0810221F86BE for ; Tue, 12 Jun 2012 07:55:53 -0700 (PDT) Received: by qabj40 with SMTP id j40so489758qab.15 for ; Tue, 12 Jun 2012 07:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=qsGCD+RBjVNh3wWgzvEL/0B7PTnmDVfrSRpeKuw9H84=; b=kY763zfjONM4RDzomMmWdb3tA2LNPs6v1Fa7zpVyRvfWBIBuq/WlkwuZ63nWla4Q3W mrxwW/f145UQvgw60d0gKOA28GsgPf9FYoeQyHKYYJCaSV7YgPvHlKqT1+G5+tyR3x40 PWPKU89RrjWE7MDABkncgNfurn3Ca8HR2vrkTgiO6+67hoVlE4YVQyYn1ucx3DMKsDAA igm4VlvxSltIxBKWaAe13xqaiFxNLeVm71e1X3IK+bjIs4V5TDhOiz92HNnHzpsceM6e Z/xKnyYgAogoLMAzt1HCQ9z3rUc3pd2s3xXOI/G9MaaJBH+xRzBkIG+ZG0riDyRCFlR7 ohGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=qsGCD+RBjVNh3wWgzvEL/0B7PTnmDVfrSRpeKuw9H84=; b=FLn4X7RiQKCqiGHLWj3xNxVf+Ro/jC9hrmWTeqjqzaEdsYRKaYrJn9o3BxfYyzr44q Xyr+nm1exEGj4+vH7glLb1phXDG0zw5b8xdU5CNm2S9R6rxX4laEebczI8rWgy2xoC+u JDkfDJWHw2+QCxqBERnQ4yVf37Lj2gjcNEkKlaMCNbEU8zJGMOV+fFBfZo7OUxt/WFQP MiPavFdt3TJNFFrNRtVB+scJhBh45mwFaYFZzfHk48FvBHC03+wX22DhUCJ2cF2jIza1 oNBxslz1pKqxa74eQ4A9PSC6FlvfvRVq9DXsszCr88oMOQvX2Sl2Hh8581798ahTaEf4 TPpg== Received: by 10.224.116.10 with SMTP id k10mr9151671qaq.76.1339512953282; Tue, 12 Jun 2012 07:55:53 -0700 (PDT) Received: by 10.224.116.10 with SMTP id k10mr9151642qaq.76.1339512953111; Tue, 12 Jun 2012 07:55:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.211 with HTTP; Tue, 12 Jun 2012 07:55:32 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 12 Jun 2012 10:55:32 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=20cf3074d5d6be069e04c247a9c6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmw6i7EvypMh1CRkWjn2St9a7WvhhWrUg4Jbt9Y41ZROt4Ul2p+7fTShT1lrcsUq4VQEslrjzVVc69vVVXNBo2WFfR5UaJkdRhpGh6RqRCz/rJLmplInMEpSGPmTrens6Pxvtzn Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What I think we need to do about ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:55:55 -0000 --20cf3074d5d6be069e04c247a9c6 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 12, 2012 at 9:57 AM, Bernard Aboba wrote: > Justin said: > > On Tue, Jun 12, 2012 at 4:53 AM, Bernard Aboba wrote: > > Issue 1 is addressed via continuing consent, no? > > > Is this frequent enough? We probably need to be able to detect failures in > ~5 seconds or so. > > [BA] Depends on the kind of failure. Removal/addition of an interface can > be detected very quickly (e.g. RFC 4436 can run in 5 ms). Detection of a > failure in the middle of the network will take longer; route flaps can > cause transient loss, but often resolve themselves quickly (under 30 > seconds) so switch in less than 15 seconds will risk false positives. > I understand what you are saying, but most people will hang up the call after ~10 seconds of silence. Given that the downside of an ICE restart is minimal, we probably want to be more aggressive here. > > WRT 2, ICE prioritizes pairs so there are shortcuts that can be taken, > depending on what you know. If an interface is down, no need to try those > host candidates. Similarly, no need to retry pairs that just failed. The > question with relay fail back is whether the allocation is still valid. > > > How does this work at the wire level? Is this a new USE-CANDIDATE ping on > the new pair from the controlling side? > > [BA] In the event of a failure, it would make sense to be aggressive to > restore media quickly. If you have a working pair, but are just looking for > a better one, you might not want to set flags until you've confirmed that > the pair is actually better. > > > 3. It seems sensible to be able to cache recent tests and not rerun them. > If that were done then full offer/answers might only generate delta tests. > > > This assumes that both sides are keeping all unused candidates alive > during the session. > > [BA] I doubt that implementations would keep relay candidates alive if > they weren't chosen. But one could cache the list of candidates from both > sides minus the relays, update the host and server reflexive candidates > and prioritize pairs. > The question is whether you could skip any tests. If a pair has been > recently demonstrated to be working (e.g. it is working currently, but > you've gotten new pairs) you can skip the test. Similarly, if it's been > marked as down. > > > > > > > On Jun 12, 2012, at 1:33 AM, "Eric Rescorla" wrote: > > > To recap what I was saying on the list: > > > > 1. Some method of determining when a candidate pair has failed. > > > > 2. Some method of failing over to another candidate pair after > > failure in as clean a fashion as possible, preferably exploiting > > the fact that we already know about other valid candidate pairs, > > if possible. Example: I had a direct and relayed pair that worked > > and I chose direct. Is there a way to fall back to relayed without > > doing a total re-ice. > > > > 3. When I discover a new candidate pair, some way of investigating > > it and maybe changing to it w/o interfering with my current active > > candidate pair. > > > > I think we need to do (1) and probably (2) now and (3) is a nice to have. > > > > -Ekr > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --20cf3074d5d6be069e04c247a9c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 12, 2012 at 9:57 AM, Bernard= Aboba <bernard_aboba@hotmail.com> wrote:
Justin said:

On Tue, Jun 12, 2012 at 4:5= 3 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrot= e:
Issue 1 is addressed via continuing consent, no?

<= /div>
Is this frequent enough? We probably need= to be able to detect failures in ~5 seconds or so.

[BA] Depe= nds on the kind of failure.=C2=A0 Removal/addition of an interface can be d= etected very quickly (e.g. RFC 4436 can run in 5 ms).=C2=A0 Detection of a = failure in the middle of the network will take longer; route flaps can caus= e transient loss, but often resolve themselves quickly (under 30 seconds) s= o switch in less than 15 seconds will risk false positives.

I understand= what you are saying, but most people will hang up the call after ~10 secon= ds of silence. Given that the downside of an ICE restart is minimal, we pro= bably want to be more aggressive here.
<= div class=3D"im">

WRT 2, ICE prioritizes pairs so there are shortcuts that can be taken, depe= nding on what you know. If an interface is down, no need to try those host = candidates. Similarly, no need to retry pairs that just failed. The questio= n with relay fail back is whether the allocation is still valid.

How does this work= at the wire level? Is this a new USE-CANDIDATE ping on the new pair from t= he controlling side?

[BA] In the event of a failure, it would = make sense to be aggressive to restore media quickly. If you have a working= pair, but are just looking for a better one, you might not want to set fla= gs until you've confirmed that the pair is actually better.=C2=A0


3. It seems sensible to be able to cache recent tests and not rerun them. I= f that were done then full offer/answers might only generate delta tests.

This assumes tha= t both sides are keeping all unused candidates alive during the session.
[BA] I doubt that implementations would keep relay candidates ali= ve if they weren't chosen.=C2=A0 But one could cache the list of candid= ates from both sides minus the relays, update the host=C2=A0 and server ref= lexive candidates and prioritize pairs.
The question is whether you could skip any tests. If a pair has been recent= ly demonstrated to be working (e.g. it is working currently, but you've= gotten new pairs) you can skip the test.=C2=A0 Similarly, if it's been= marked as down.

=C2=A0



On Jun 12, 2012, at 1:33 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:

> To recap what I was saying on the list:
>
> 1. Some method of determining when a candidate pair has failed.
>
> 2. Some method of failing over to another candidate pair after
> failure in as clean a fashion as possible, preferably exploiting
> the fact that we already know about other valid candidate pairs,
> if possible. Example: I had a direct and relayed pair that worked
> and I chose direct. Is there a way to fall back to relayed without
> doing a total re-ice.
>
> 3. When I discover a new candidate pair, some way of investigating
> it and maybe changing to it w/o interfering with my current active
> candidate pair.
>
> I think we need to do (1) and probably (2) now and (3) is a nice to ha= ve.
>
> -Ekr
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


--20cf3074d5d6be069e04c247a9c6-- From anant@mozilla.com Tue Jun 12 08:07:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB71021F865B for ; Tue, 12 Jun 2012 08:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_15=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upO8ks7wBmaF for ; Tue, 12 Jun 2012 08:07:38 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABD921F8643 for ; Tue, 12 Jun 2012 08:07:37 -0700 (PDT) Received: from kix.local (18.225.181.62.in-addr.dgcsystems.net [62.181.225.18]) (Authenticated sender: anarayanan@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 4E2C8F29A0; Tue, 12 Jun 2012 08:07:34 -0700 (PDT) Message-ID: <4FD75B24.6020501@mozilla.com> Date: Tue, 12 Jun 2012 17:07:16 +0200 From: Anant Narayanan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Harald Alvestrand References: <4FD71670.9050900@alvestrand.no> In-Reply-To: <4FD71670.9050900@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAME as a media stream identifier - what I don't think works X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:07:39 -0000 On 6/12/12 12:14 PM, Harald Alvestrand wrote: > pc = new PeerConnection(); > > GetUserMedia(..., function(stream) { > stream1 = stream; As per my understanding of the gUM spec, this line: > stream2 = new MediaStream(stream1.audioTracks, stream1.videoTracks); indicates that the audio and video tracks are *copied* into stream2, and are not references. Consider, for instance, that if a resolution change was made to a track in stream2, the track from the same source in stream1 would remain unchanged. Thus, I'd expect the following: > ..... stuff to start connecting .... > > pc.addStream(stream1); > pc.addStream(stream2); > > offer = pc.createOffer(....); > > With MSID, the offer will look like this: > > .... > m=audio > a=ssrc:1234 msid=xyzzy a0 > a=ssrc:1234 msid=xyww a0 > ... > m=video > a=ssrc:1256 msid=xyzzy v0 > a=ssrc:1256 msid=xyww v0 to look like: m=audio a=ssrc:1234 cname:144a a=ssrc:4321 cname:1e24 ... m=video a=ssrc:1256 cname:144a a=ssrc:6521 cname:1e24 instead. And, this: > and the expectation on the recipient side is that you will get > pc.onaddstream called with: > > 1) stream with id = xyzzy, audio and video > 2) stream with id = xyww, audio and video would remain the same, except with the IDs substituted by CNAMEs. -Anant From bernard_aboba@hotmail.com Tue Jun 12 08:26:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5A521F86BD for ; Tue, 12 Jun 2012 08:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.784 X-Spam-Level: X-Spam-Status: No, score=-101.784 tagged_above=-999 required=5 tests=[AWL=0.813, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7z904Z60J2K for ; Tue, 12 Jun 2012 08:26:43 -0700 (PDT) Received: from blu0-omc1-s28.blu0.hotmail.com (blu0-omc1-s28.blu0.hotmail.com [65.55.116.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8109121F86BE for ; Tue, 12 Jun 2012 08:26:43 -0700 (PDT) Received: from BLU169-W107 ([65.55.116.7]) by blu0-omc1-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 08:26:43 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_e0544a6a-d4a8-4df6-9a6b-4bb8230676a7_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Date: Tue, 12 Jun 2012 08:26:42 -0700 Importance: Normal In-Reply-To: References: , , , MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2012 15:26:43.0002 (UTC) FILETIME=[C54989A0:01CD48AF] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What I think we need to do about ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:26:44 -0000 --_e0544a6a-d4a8-4df6-9a6b-4bb8230676a7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Justin said: I understand what you are saying=2C but most people will hang up the call a= fter ~10 seconds of silence. Given that the downside of an ICE restart is m= inimal=2C we probably want to be more aggressive here. [BA] If you're asking whether you can start testing alternative pairs quick= ly=2C sure. With the built-in rate limiting there won't be any damage done= by that=2C and it will take some time to confirm a working alternative pai= r anyway. My comment was just about the likelihood that the issue with the existing p= air is just a temporary glitch. That would suggest that flags not be set o= n the alternative exploration until you decide the existing pair is down.=20 = --_e0544a6a-d4a8-4df6-9a6b-4bb8230676a7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Justin said:

I un= derstand what you are saying=2C but most people will hang up the call after= ~10 seconds of silence. Given that the downside of an ICE restart is minim= al=2C we probably want to be more aggressive here.

[BA] If you're as= king whether you can start testing alternative pairs quickly=2C sure. = =3B With the built-in rate limiting there won't be any damage done by that= =2C and it will take some time to confirm a working alternative pair anyway= .

My comment was just about the likelihood that the issue with the e= xisting pair is just a temporary glitch. =3B That would suggest that fl= ags not be set on the alternative exploration until you decide the existing= pair is down.
= --_e0544a6a-d4a8-4df6-9a6b-4bb8230676a7_-- From harald@alvestrand.no Tue Jun 12 08:26:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8535021F86EA for ; Tue, 12 Jun 2012 08:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.799 X-Spam-Level: X-Spam-Status: No, score=-108.799 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 aPUY32IsxOOQ for ; Tue, 12 Jun 2012 08:26:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA8A21F86E0 for ; Tue, 12 Jun 2012 08:26:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73CBD39E194; Tue, 12 Jun 2012 17:27:08 +0200 (CEST) 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 XmW8AnjTZm9L; Tue, 12 Jun 2012 17:27:06 +0200 (CEST) Received: from [10.59.1.65] (18.225.181.62.in-addr.dgcsystems.net [62.181.225.18]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9C7C239E062; Tue, 12 Jun 2012 17:27:06 +0200 (CEST) Message-ID: <4FD75FB8.5090200@alvestrand.no> Date: Tue, 12 Jun 2012 17:26:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Anant Narayanan References: <4FD71670.9050900@alvestrand.no> <4FD75B24.6020501@mozilla.com> In-Reply-To: <4FD75B24.6020501@mozilla.com> Content-Type: multipart/alternative; boundary="------------070206030204020308080009" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] CNAME as a media stream identifier - what I don't think works X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:26:51 -0000 This is a multi-part message in MIME format. --------------070206030204020308080009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/12/2012 05:07 PM, Anant Narayanan wrote: > On 6/12/12 12:14 PM, Harald Alvestrand wrote: >> pc = new PeerConnection(); >> >> GetUserMedia(..., function(stream) { >> stream1 = stream; > > As per my understanding of the gUM spec, this line: > >> stream2 = new MediaStream(stream1.audioTracks, >> stream1.videoTracks); > > indicates that the audio and video tracks are *copied* into stream2, > and are not references. I have concluded from the discussions this week that we're not of one mind on this, and that various items, including this, make more sense if we see them as references. The actual language for the constructor is: "Addtracktostream'saudio track list." There's nothing here about making a copy of /track/. Remember that the original specification (a year ago) had chained tracks feeding into other tracks; we simplified this model to a model where a track always links a source to a sink, not to another track. I think that our previous day's discussion has concluded that if we want to make a change to a track, and not have that change affect another track, we have to make a copy, and we have to make it explicit. For the (I think normal) case where we don't manipulate requirements on tracks, or are happy to have any changes affect all copies of the track, we don't need the copy. > Consider, for instance, that if a resolution change was made to a > track in stream2, the track from the same source in stream1 would > remain unchanged. > > Thus, I'd expect the following: > >> ..... stuff to start connecting .... >> >> pc.addStream(stream1); >> pc.addStream(stream2); >> >> offer = pc.createOffer(....); >> >> With MSID, the offer will look like this: >> >> .... >> m=audio >> a=ssrc:1234 msid=xyzzy a0 >> a=ssrc:1234 msid=xyww a0 >> ... >> m=video >> a=ssrc:1256 msid=xyzzy v0 >> a=ssrc:1256 msid=xyww v0 > > to look like: > > m=audio > a=ssrc:1234 cname:144a > a=ssrc:4321 cname:1e24 > ... > m=video > a=ssrc:1256 cname:144a > a=ssrc:6521 cname:1e24 > > instead. This markup (which is actually already standardized) says two things: - the sender has two synchronization contexts, 144a and 1e24 - the recipient has no information about whether or not these are synchronized to the same clock This also means that the packets of each stream are transmitted twice, of course. > And, this: > >> and the expectation on the recipient side is that you will get >> pc.onaddstream called with: >> >> 1) stream with id = xyzzy, audio and video >> 2) stream with id = xyww, audio and video > > would remain the same, except with the IDs substituted by CNAMEs. That's a reasonable interpretation. Is it the one we want to make? --------------070206030204020308080009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/12/2012 05:07 PM, Anant Narayanan wrote:
On 6/12/12 12:14 PM, Harald Alvestrand wrote:
pc = new PeerConnection();

GetUserMedia(..., function(stream) {
      stream1 = stream;

As per my understanding of the gUM spec, this line:

      stream2 = new MediaStream(stream1.audioTracks, stream1.videoTracks);

indicates that the audio and video tracks are *copied* into stream2, and are not references.
I have concluded from the discussions this week that we're not of one mind on this, and that various items, including this, make more sense if we see them as references.

The actual language for the constructor is:

  "Add track to stream’s audio track list."

There's nothing here about making a copy of track.

Remember that the original specification (a year ago) had chained tracks feeding into other tracks; we simplified this model to a model where a track always links a source to a sink, not to another track.

I think that our previous day's discussion has concluded that if we want to make a change to a track, and not have that change affect another track, we have to make a copy, and we have to make it explicit. For the (I think normal) case where we don't manipulate requirements on tracks, or are happy to have any changes affect all copies of the track, we don't need the copy.
Consider, for instance, that if a resolution change was made to a track in stream2, the track from the same source in stream1 would remain unchanged.

Thus, I'd expect the following:

..... stuff to start connecting ....

pc.addStream(stream1);
pc.addStream(stream2);

offer = pc.createOffer(....);

With MSID, the offer will look like this:

....
m=audio
a=ssrc:1234 msid=xyzzy a0
a=ssrc:1234 msid=xyww a0
...
m=video
a=ssrc:1256 msid=xyzzy v0
a=ssrc:1256 msid=xyww v0

to look like:

m=audio
a=ssrc:1234 cname:144a
a=ssrc:4321 cname:1e24
...
m=video
a=ssrc:1256 cname:144a
a=ssrc:6521 cname:1e24

instead.

This markup (which is actually already standardized) says two things:

- the sender has two synchronization contexts, 144a and 1e24
- the recipient has no information about whether or not these are synchronized to the same clock

This also means that the packets of each stream are transmitted twice, of course.
And, this:

and the expectation on the recipient side is that you will get
pc.onaddstream called with:

1) stream with id = xyzzy, audio and video
2) stream with id = xyww, audio and video

would remain the same, except with the IDs substituted by CNAMEs.


That's a reasonable interpretation. Is it the one we want to make?



--------------070206030204020308080009-- From stefan.lk.hakansson@ericsson.com Tue Jun 12 12:55:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE2621F86FE for ; Tue, 12 Jun 2012 12:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnkZadOjOVNc for ; Tue, 12 Jun 2012 12:55:46 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0265521F86EA for ; Tue, 12 Jun 2012 12:55:45 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-73-4fd79ec0d055 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1F.62.00702.0CE97DF4; Tue, 12 Jun 2012 21:55:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Tue, 12 Jun 2012 21:55:44 +0200 Message-ID: <4FD79EBF.8080600@ericsson.com> Date: Tue, 12 Jun 2012 21:55:43 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD71670.9050900@alvestrand.no> <4FD75B24.6020501@mozilla.com> <4FD75FB8.5090200@alvestrand.no> In-Reply-To: <4FD75FB8.5090200@alvestrand.no> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvre7Bedf9DV67W6z9187uwOixZMlP pgDGKC6blNSczLLUIn27BK6MA6f3shX8Za1YfeQQUwPjW5YuRk4OCQETia8zTzFC2GISF+6t Z+ti5OIQEjjFKPFq/kcWCGc5o8SU8/NYQap4BbQl9rbNALI5OFgEVCXePgVrZhOwkVjbPYUJ JCwqECax+oEGRLWgxMmZT8B2iQgIS2x91csEYgsLhEpc2v6TGcQWEsiReDbhIVicU0BX4tCK G+wgY5gF7CUebC0DCTMLyEtsfzsHqlxX4t3re6wTGAVmIdkwC6FjFpKOBYzMqxiFcxMzc9LL zfVSizKTi4vz8/SKUzcxAsPu4JbfBjsYN90XO8QozcGiJM6rp7rfX0ggPbEkNTs1tSC1KL6o NCe1+BAjEwenVAOj9pMDX4+XnGTluLDA+PnGqG8O6p+37ivRjnRi03whwcOdEHf9VXV40vtN 3xTvd/JxpjOu1VnkI1jH7qt0nunvS95y65iYzv3TAhmnztHSrn4cHXPMf7bk2ZCnnVtrpKcd jLqs0Ku3ZEUiS+/F4l7X5hWcyRObbz9Ydbowjn3DCYOTj/4H/JmvxFKckWioxVxUnAgAEhmQ MQkCAAA= Subject: Re: [rtcweb] CNAME as a media stream identifier - what I don't think works X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 19:55:47 -0000 On 06/12/2012 05:26 PM, Harald Alvestrand wrote: > On 06/12/2012 05:07 PM, Anant Narayanan wrote: >> On 6/12/12 12:14 PM, Harald Alvestrand wrote: >>> pc = new PeerConnection(); >>> >>> GetUserMedia(..., function(stream) { >>> stream1 = stream; >> >> As per my understanding of the gUM spec, this line: >> >>> stream2 = new MediaStream(stream1.audioTracks, stream1.videoTracks); >> >> indicates that the audio and video tracks are *copied* into stream2, >> and are not references. > I have concluded from the discussions this week that we're not of one > mind on this, and that various items, including this, make more sense if > we see them as references. They would have to be separate enough to allow individual enable/disable in any case. From stefan.lk.hakansson@ericsson.com Tue Jun 12 13:38:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7412E11E8088 for ; Tue, 12 Jun 2012 13:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg4so1iXzDXy for ; Tue, 12 Jun 2012 13:37:59 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB5011E8095 for ; Tue, 12 Jun 2012 13:37:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-d1-4fd7a8a1bf58 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F0.55.28636.2A8A7DF4; Tue, 12 Jun 2012 22:37:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Tue, 12 Jun 2012 22:37:53 +0200 Message-ID: <4FD7A8A0.8080501@ericsson.com> Date: Tue, 12 Jun 2012 22:37:52 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD71670.9050900@alvestrand.no> <4FD75B24.6020501@mozilla.com> In-Reply-To: <4FD75B24.6020501@mozilla.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre6iFdf9Db5t47NY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGT0rTrIUNHNVdDy+xdLA+I29i5GTQ0LAROLtgT4WCFtM4sK9 9WxdjFwcQgKnGCWu/2plhnCWM0qc+rOEFaSKV0Bb4tT2aWwgNouAqsTL62vButkEbCTWdk9h 6mLk4BAVCJNY/UADolxQ4uTMJ2AlIgLCEltf9TKB2MICoRKXtv9kBrGFBLwl/v/9BVbDCTR+ 7uPpYHFmAVuJC3Ous0DY8hLb386BqteVePf6HusERoFZSFbMQtIyC0nLAkbmVYzCuYmZOenl hnqpRZnJxcX5eXrFqZsYgeF3cMtv3R2Mp86JHGKU5mBREuflStrvLySQnliSmp2aWpBaFF9U mpNafIiRiYNTqoHRnucet0VzCMfE/wYcHtJ/frl5L45h4xA8eH/OhZCJSeuZJFesf1XhpLFE wS1l/jzdqvh3N97XKZX115Rf+sP79+OjzSYZB2uucMu/eSjmJSHbWfgtSeVq6kzZj+XdxQue 9f43Sm+Jz5pdcVX5vMJKJUXbzwJ60nuXnzNbs+6ZUKTArgjlqANKLMUZiYZazEXFiQCqdMng DQIAAA== Subject: Re: [rtcweb] CNAME as a media stream identifier - what I don't think works X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 20:38:00 -0000 On 06/12/2012 05:07 PM, Anant Narayanan wrote: > On 6/12/12 12:14 PM, Harald Alvestrand wrote: >> pc = new PeerConnection(); >> >> GetUserMedia(..., function(stream) { >> stream1 = stream; > > As per my understanding of the gUM spec, this line: > >> stream2 = new MediaStream(stream1.audioTracks, stream1.videoTracks); > > indicates that the audio and video tracks are *copied* into stream2, and > are not references. Consider, for instance, that if a resolution change > was made to a track in stream2, the track from the same source in > stream1 would remain unchanged. This is a bit unclear to me. What would a resolution change really mean in this case? To me the resolution (when a camera is used as source) would be the resolution delivered by the camera. Can it deliver two (or more) resolutions at the same time (perhaps also with different frame rates, aspect rations and so on)? To me it makes most sense (if the application is going to explicitly ask for specific resolution, frame rate, aspec ration) to ask for it at getUserMedia time. If the app does not ask for this explicitly, at least the suitable resolution would be known by the browser whenever the video is played in a video element (from the size of it). From andrew.hutton@siemens-enterprise.com Tue Jun 12 13:39:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FBA11E80AA for ; Tue, 12 Jun 2012 13:39:38 -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 DaGx1ehEuoD9 for ; Tue, 12 Jun 2012 13:39:37 -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 E20B411E8088 for ; Tue, 12 Jun 2012 13:39:36 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5E03B23F064D; Tue, 12 Jun 2012 22:39:35 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Tue, 12 Jun 2012 22:39:35 +0200 From: "Hutton, Andrew" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 Thread-Index: AQHNR1MbQM1MF1ifh0S2QB0C2qGEl5b3JU3g Date: Tue, 12 Jun 2012 20:39:34 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF024368@MCHP04MSX.global-ad.net> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <4FD516B3.40501@alvestrand.no> In-Reply-To: <4FD516B3.40501@alvestrand.no> 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: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 20:39:38 -0000 Hi, My suggestion would be to remove the statements from each use case regardin= g eavesdropping and replace it with bullets in section 4.1 for consideratio= ns which apply to all use cases. These should state that all media streams = and data channels must be integrity and confidentiality protected. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: 10 June 2012 23:51 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and- > requirements-07 >=20 > On 06/10/2012 05:33 PM, Hutton, Andrew wrote: > > Hi, > > > > Some comments on draft-ietf-rtcweb-use-cases-and-requirements-07. > > > > Section 4.1.1.1 (Simple Video Communication Service) contains the > statement "Each user can also pause sending of media (audio, video, or > both) and mute incoming media". I think this and the associated > requirements need some clarification for example whether the > requirement is to control the direction of the media and therefore > requires the generation of a new SDP offer with for example a direction > of "recvonly/inactive". The only associated requirement seems to be A8 > but this does not help clarify what is meant by "pause" in the use > case. It needs to be clarified whether the pause/resume/mute are > actions within the browser or are actions which result in notifications > to the remote user. > > > > Maybe we could add a use case which involves controlling the > direction of multiple streams to emulate switching between different > users in a multiparty call scenario. > > > > > > The statement "It is essential that the communication cannot be > eavesdropped" appears in all use cases so could be moved to section 4.1 > but I think it needs to be reworded in terms of the media always being > encrypted as I don't like the term "eavesdropped" which is not defined. > If we want to define the term, we might want to use the term > "wiretapping", and refer to RFC 2804 for the definition. >=20 > (having been involved in that discussion, I've got some personal > fondness for that definition...) >=20 >=20 > > > > Regards > > Andy > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Markus.Isomaki@nokia.com Tue Jun 12 13:54:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F220311E80C5 for ; Tue, 12 Jun 2012 13:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.107 X-Spam-Level: X-Spam-Status: No, score=-4.107 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ESTABLISH2=2.492, 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 wuHRvOxa6c18 for ; Tue, 12 Jun 2012 13:54:11 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0617411E8073 for ; Tue, 12 Jun 2012 13:54:10 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5CKs8DS005951 for ; Tue, 12 Jun 2012 23:54:09 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 23:54:08 +0300 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.74]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Tue, 12 Jun 2012 22:54:08 +0200 From: To: Thread-Topic: Interface switching use case and the basic needs Thread-Index: Ac1I3YCkLmPNdotdR5uuxDlimnzEOg== Date: Tue, 12 Jun 2012 20:54:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.103.36.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jun 2012 20:54:08.0565 (UTC) FILETIME=[82F48E50:01CD48DD] X-Nokia-AV: Clean Subject: [rtcweb] Interface switching use case and the basic needs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 20:54:12 -0000 Hi, Here is some input on the interface switching use case from mobile device p= erspective: Most today's mobile devices (smartphones, tablets) work so, that only a sin= gle interface is connected at a time. This is for power conservation reason= s, plus no-one has figured out what to do with the second active interface.= In practice the two interfaces are always cellular (of some sort) and Wi-F= i. A typical policy is that any Wi-Fi is preferred over cellular, but in th= eory some Wi-Fi networks could have a lower priority too. If a higher prior= ity interface (network) becomes available, the device connects to it, and a= fter that, switches off the lower priority one. When the preferred network = becomes unavailable, the device tries to connect to the second best option.= =20 Applications usually have no control on this. For instance, if the user is = having a VoIP call over cellular and walks to Wi-Fi coverage, interface swi= thing is done (after the Wi-Fi is discovered, which may take a few minutes = depending on the scanning interval), and the call is lost (unless the app u= ses some magic to keep it up). Depending on the environments, apps usually = listen to events indicating interfaces going up and down. Many apps today a= re capable of dealing with this. For instance apps that have persistent TCP= connections simply re-establish them over the new interface. Depending on = the app protocol they will also have to do things like re-register (SIP) on= top of that. If there's nothing time critical going on, the user won't not= ice anything. In the worst case the other end is just sending something ove= r TCP when the connection is abandoned and that requires some app layer rec= overy.=20 I don't know how well browsers and web apps in general deal with this. HTTP= is easy to deal with, as its state is not tied to e.g. a particular TCP co= nnection. Pending requests, for instance hanging GETs, can be re-issued ove= r a new TCP connection. How about Websocket protocol? Is it possible to sim= ply re-establisth its TCP connection without the JS app using it noticing? = I suppose so, but also the recovery of lost data has to be dealt with. The = main question is whether the JS app would need to know/react in any way. In= WebRTC the real-time sessions would often be "signaled" over Websockets or= hanging HTTP GETs, so making that part recover smoothly from underlying TC= P connections getting dropped would be essential. The real-time media recovery/update would be a great feature, but let's kee= p in mind also the more basic needs. Can they be dealt with a smart browser= implementation, or is there a need to expose something to the JS app too? Markus From martin.thomson@gmail.com Tue Jun 12 15:52:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCD621F86C9 for ; Tue, 12 Jun 2012 15:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=-2.200, 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 F4o8ZzvuGIt4 for ; Tue, 12 Jun 2012 15:52:04 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2A921F86C8 for ; Tue, 12 Jun 2012 15:52:04 -0700 (PDT) Received: by bkty8 with SMTP id y8so5784309bkt.31 for ; Tue, 12 Jun 2012 15:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WsdexMRv3BkTbUk6/gfpMdaWTR5qp9jyWLcljnHUGJ0=; b=M4SLfVCSbSMoAlhb+S5bsVm/sApLkB+Pu9nsbHDj3rB733EBh7BVpubri9XXRv9/L3 w+7xV2IkUnLqAuutod5tgu4WY6OM6Lkdp0nMRdivuV2vbG4HWTQhScxG/tgMWenGr/rf 9FyiNBDEEdXCIo0eXAsooo7W6+fQki2JGDaRyEWQddJJkuq+Ue+ohIv9FoO98ero8FNA e5862pW4UoZhJhS73xMU6jHEXuNm0/SuW+V+WMxopeodOaM0lRvbzscBX8YSN3F4PVoe 9TRxwyDYfKMRtw6M97LDnyGEDmcHXqlCqwjIbycThLGZYII2wZzsH458exnzcSBb4QOy P6Dw== MIME-Version: 1.0 Received: by 10.204.128.149 with SMTP id k21mr12265665bks.42.1339541523170; Tue, 12 Jun 2012 15:52:03 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 12 Jun 2012 15:52:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jun 2012 15:52:03 -0700 Message-ID: From: Martin Thomson To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Interface switching use case and the basic needs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 22:52:05 -0000 On 12 June 2012 13:54, wrote: > Most today's mobile devices (smartphones, tablets) work so, that only a single interface is connected at a time. This is for BTW, this one interface at a time behaviour is really annoying in some situations. WiFi networks frequently require sign-on, which means that you migrate to the WiFi and you spend ages mucking around with the login, or you have to turn off WiFi in order to reassociate with the MME. Either way, you have a significant down time window. This happened to me at SFO on the way over, when I realized that my "mobile boarding pass" was necessary to enter the security line. It took a couple of minutes to resolve. This is a bad user experience as a result of this sort of rule, applied blindly. > How about Websocket protocol? That doesn't work. The application is forced to recover. Most of the reasons for using websockets involve tying some sort of state to the connection. Sure, that's not robust, but it is easier to fail at that point than spend the effort dealing with either statelessness (for which you are using HTTP anyway) or state recovery, which is expensive to implement. > The real-time media recovery/update would be a great feature, but let's keep in mind also the more basic needs. Can they be dealt with a smart browser implementation, or is there a need to expose something to the JS app too? Sure, the JS app gets a disconnect from websockets. It had better deal. The fact that you have had a switchover does require effectively a complete reboot of ICE, which a realtime app ultimately needs to deal with by signaling candidates...at a minimum. This is covered by what EKR sent out and I'm sure that he will have a proposal for the API around this. If he doesn't do that soon, I'll propose something he wont like. --Martin From tterriberry@mozilla.com Tue Jun 12 22:39:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195C621F8716 for ; Tue, 12 Jun 2012 22:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu3idhWNd2+z for ; Tue, 12 Jun 2012 22:39:41 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9A44F21F870F for ; Tue, 12 Jun 2012 22:39:41 -0700 (PDT) Received: from [10.43.3.16] (unknown [212.112.167.85]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 052FAF26D6 for ; Tue, 12 Jun 2012 22:39:32 -0700 (PDT) Message-ID: <4FD82793.9010506@mozilla.com> Date: Tue, 12 Jun 2012 22:39:31 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20120113 SeaMonkey/2.4.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] RTP clock rates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 05:39:42 -0000 In discussion at the interim meeting yesterday, Harald expressed a desire to prohibit a sender from changing the Payload Type associated with an SSRC to one that runs at a different clock rate. This raised the question of what clock rates are supported for various codecs where we might want to switch, specifically Opus and DTMF. draft-spittka-payload-rtp-opus-00 specifies that the clock rate for Opus will always be 48 kHz. According to RFC 4733, DTMF supports any integer clock rate. The "duration" field for a DTMF telephone event is a 16-bit unsigned integer, giving a maximum duration of 1.365 seconds per packet. Events can be extended beyond this by splitting them into segments and sending a separate packet for each segment (using the 'E' bit to mark the last one). So I don't think this prohibition imposes any serious limitations, at least with regards to Opus and DTMF. From harald@alvestrand.no Wed Jun 13 00:23:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F3021F8525 for ; Wed, 13 Jun 2012 00:23:01 -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.900, 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 G6-dldCjLegw for ; Wed, 13 Jun 2012 00:23:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 13C7521F85A5 for ; Wed, 13 Jun 2012 00:22:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C66039E179 for ; Wed, 13 Jun 2012 09:23:16 +0200 (CEST) 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 A8BS1whB-cBH for ; Wed, 13 Jun 2012 09:23:15 +0200 (CEST) Received: from [10.59.1.65] (18.225.181.62.in-addr.dgcsystems.net [62.181.225.18]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8F6EF39E029 for ; Wed, 13 Jun 2012 09:23:15 +0200 (CEST) Message-ID: <4FD83FD0.3070806@alvestrand.no> Date: Wed, 13 Jun 2012 09:22:56 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD82793.9010506@mozilla.com> In-Reply-To: <4FD82793.9010506@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTP clock rates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 07:23:01 -0000 On 06/13/2012 07:39 AM, Timothy B. Terriberry wrote: > In discussion at the interim meeting yesterday, Harald expressed a > desire to prohibit a sender from changing the Payload Type associated > with an SSRC to one that runs at a different clock rate. To be more precise: I suggested that we should incorporate by reference the advice in draft-ietf-avtext-multiple-clock-rates-05: 4.1. RTP Sender (with RTCP) An RTP Sender with RTCP turned on MUST use a different SSRC for each different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST be used if the clock rate switches back to a value already seen in the RTP stream. > This raised the question of what clock rates are supported for various > codecs where we might want to switch, specifically Opus and DTMF. > > draft-spittka-payload-rtp-opus-00 specifies that the clock rate for > Opus will always be 48 kHz. According to RFC 4733, DTMF supports any > integer clock rate. The "duration" field for a DTMF telephone event is > a 16-bit unsigned integer, giving a maximum duration of 1.365 seconds > per packet. Events can be extended beyond this by splitting them into > segments and sending a separate packet for each segment (using the 'E' > bit to mark the last one). > > So I don't think this prohibition imposes any serious limitations, at > least with regards to Opus and DTMF. This of course means that if one wants to use DTMF with multiple codecs that have different clock rates, there must be multiple payload types that identify as DTMF - one for each clock rate. The same issue arises with CN (Comfort Noise). Not a problem, as long as implementors are aware, I think. Harald From pravindran@sonusnet.com Wed Jun 13 00:43:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EA221F8642 for ; Wed, 13 Jun 2012 00:43:00 -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 3CjOVYTgqknQ for ; Wed, 13 Jun 2012 00:43:00 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id DEE8D21F8627 for ; Wed, 13 Jun 2012 00:42:59 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKT9hEg/mP14Ekb9GlvK+xkiZ4Gq3fmirX@postini.com; Wed, 13 Jun 2012 00:43:00 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 13 Jun 2012 03:43:32 -0400 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 13 Jun 2012 13:12:53 +0530 From: "Ravindran, Parthasarathi" To: "rtcweb@ietf.org" Thread-Topic: Cloning mechanism in JS Thread-Index: Ac1JOC9SR+YJMeexSrigSaykl2iilQ== Date: Wed, 13 Jun 2012 07:42:52 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160496C0@inba-mail02.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Cloning mechanism in JS X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 07:43:00 -0000 Hi all, I'm writing this mail, as I don't have facility to write in the Jabber room= . Cloning mechanism is 1:1 mapping with SIP forking (serial & parallel). The = cloned peerconnection aggregation is managed by JavaScript and which peerco= nnection get priority is matter of JS decision. Each cloned peerconnection will have the initial offer. The number of cloni= ng shall be decided by the application. As a simple thumb rule, before ever= y the (early) answer, cloning of the peerconnection shall be done till the = application wants it. This model helps for other RTP topologies like RTP mi= xer in WebRTC in the future. In a way, PRANSWER state itself is not required. Thanks Partha=20 From harald@alvestrand.no Wed Jun 13 01:16:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B3021F860E for ; Wed, 13 Jun 2012 01:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 iCFEEY0iwl07 for ; Wed, 13 Jun 2012 01:16:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B33B221F85D1 for ; Wed, 13 Jun 2012 01:16:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC83739E179 for ; Wed, 13 Jun 2012 10:17:03 +0200 (CEST) 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 1AEqYuKl4pZs for ; Wed, 13 Jun 2012 10:17:02 +0200 (CEST) Received: from [10.59.1.65] (18.225.181.62.in-addr.dgcsystems.net [62.181.225.18]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A5EBD39E029 for ; Wed, 13 Jun 2012 10:17:02 +0200 (CEST) Message-ID: <4FD84C66.2030806@alvestrand.no> Date: Wed, 13 Jun 2012 10:16:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD7069C.8080803@ifi.uio.no> <4FD707AD.1040601@mozilla.com> <4FD70E1D.10509@ifi.uio.no> In-Reply-To: <4FD70E1D.10509@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Question about usage of data traffic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 08:16:43 -0000 The reason for the initial data use cases was that we wanted to focus on the stuff that *couldn't* be done by bouncing data off a server; non-time-sensitive bulk file transfer can certainly be done via a server, even though that may not be optimal. That said, we've always expected that once the data transfer capability is in place, we'll have plenty of people wanting to use it in "unexpected" ways. The important RTCWEB-specific requirement from the file transfer use case is probably that IF file transfer is done in a peer-to-peer fashion, within the RTCWEB context, it MUST be able to run without degrading the quality of the real time media. On 06/12/2012 11:38 AM, Michael Welzl wrote: > On 6/12/12 11:11 AM, Timothy B. Terriberry wrote: >> Michael Welzl wrote: >>> What's different here is that we're in these cases dealing with greedy, >>> non-latency-critical traffic, and possibly lots of it. Could this even >>> be a new use case? >> >> There is currently a "Simple Video Communication Service with file >> exchange" use case (see Section 4.2.8 in >> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-08). >> Are there additional derived requirements that are needed to support >> this use case? > First: very sorry for missing this one! I looked at this very draft > again just yesterday, but somehow didn't notice the file transfer bit. > On a side note, when looking through the requirements derived from > this use case now, I got the impression that it would have been more > reader-friendly to write: > "In addition to the Simple Video Communication Service use-case, this > use-case has the following requirements:" and list just the new ones. > > Second: I don't think that there are additional requirements derived > from that, but it can have architectural implications. (i.e. what is > derived is, perhaps, a new property). => "file transfer" should then > be a part of the use cases on the list in the slide set I mentioned. > (I'm saying that because the slide asks: "others?") > > Given that file transfers are "part of the plan", I just think it's > important for all of us to understand that there may be a lot of data > traffic too (instead of pictures, people may be sending a movie... or > you could even have a website offering *nothing but* a file transfer > service?! I have a feeling that this could even turn into an > unintended "killer app" for rtcweb :-) ). > > Cheers, > Michael > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Wed Jun 13 01:25:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060E021F8661 for ; Wed, 13 Jun 2012 01:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-1.100, 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 rcOEQj7Z12Tn for ; Wed, 13 Jun 2012 01:25:37 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDD7121F8620 for ; Wed, 13 Jun 2012 01:25:36 -0700 (PDT) Received: by bkty8 with SMTP id y8so283498bkt.31 for ; Wed, 13 Jun 2012 01:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vnscXPruDTwYdnEaABmvVaWnoIk2tgEqnB12kYBz4uE=; b=Z7X7PBkYE181qgrusE0DOVrxewyNZwPCshhDp6o8ZIOuNgeg2XizFK97gv5oTuKWoy 0gptoUCpIaeljptC4oKyg4/xZcyMQ4PJr9RePREKY9QC/12wYCi0C5j0dxpTXZ4EwX+p wQY3mmwqMegEItFyLzxMeMoqXugWNPPxUiNVxFSynZ85vYq2Jghwg3v8SgpD5Jir8m30 cI/RZ5glcTdb/xEVarY4Gb3FMeEg5wwVIsiF5MzgoeZQzjINxu5O4qqazM0cdbumYEde CWQo5rhH76cQoXdgvgiqHPzuW5Q8uauKeRdHI1pkgFp5eI+G3kZV0b5u5oaG0r0jlpMf BxQA== MIME-Version: 1.0 Received: by 10.204.150.84 with SMTP id x20mr12678826bkv.26.1339575935661; Wed, 13 Jun 2012 01:25:35 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Wed, 13 Jun 2012 01:25:35 -0700 (PDT) Date: Wed, 13 Jun 2012 01:25:35 -0700 Message-ID: From: Martin Thomson To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Cloning === bad X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 08:25:38 -0000 I think that there is a bad assumption at play in this proposal that I think is important to highlight. That assumption is, that SIP is the only mechanism by which we are signaling. This is already a problem because it is possible to enter a deadlock state in the offer answer state machine that requires application-level intelligence to address. From harald@alvestrand.no Wed Jun 13 02:26:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F74E21F8570 for ; Wed, 13 Jun 2012 02:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 vKO3qJk2a+5Q for ; Wed, 13 Jun 2012 02:26:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AE8B021F8564 for ; Wed, 13 Jun 2012 02:26:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EEF339E0F0 for ; Wed, 13 Jun 2012 11:26:26 +0200 (CEST) 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 BA1sgL5NUQvV for ; Wed, 13 Jun 2012 11:26:25 +0200 (CEST) Received: from [10.59.1.65] (18.225.181.62.in-addr.dgcsystems.net [62.181.225.18]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B5BBB39E029 for ; Wed, 13 Jun 2012 11:26:25 +0200 (CEST) Message-ID: <4FD85CAE.7090601@alvestrand.no> Date: Wed, 13 Jun 2012 11:26:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Cloning === bad X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 09:26:05 -0000 On 06/13/2012 10:25 AM, Martin Thomson wrote: > I think that there is a bad assumption at play in this proposal that I > think is important to highlight. > > That assumption is, that SIP is the only mechanism by which we are > signaling. This is already a problem because it is possible to enter a > deadlock state in the offer answer state machine that requires > application-level intelligence to address. I don't believe there's any such assumption here. Most of the demos and applications that have been shown on top of WebRTC don't have a single line referencing SIP in them. The assumption I hear made (which I also have some doubts about) is that it *must* be *possible* to establish interworking with all the variants of functionality done by equipment using the SIP prtocol for signalling - that is, the answer to the question of "what do I do in the case that SIP uses parallel forking for" must have an answer. Today's poll result on forking seems to be "in version 1.0, we'll take the same action as SIP devices that don't support parallel forking" - ie "make it someone else's problem". > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Wed Jun 13 03:01:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A6921F867A for ; Wed, 13 Jun 2012 03:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 MJvDczNuPNaE for ; Wed, 13 Jun 2012 03:01:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42CF121F8675 for ; Wed, 13 Jun 2012 03:01:14 -0700 (PDT) Received: by vcqp1 with SMTP id p1so240846vcq.31 for ; Wed, 13 Jun 2012 03:01:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=IJAjTpZ79o7EatuL/IBd/cNCRuB2EHZrw9rzqC6xOSs=; b=VaO53oSMx9OhuUfPxgr28+mRSYrfmwtW0/onuYZAvb1pRy139kcKNu6Za7+Ov6Igox dYAlU6xcNJx2bf7f0Vj0Jk303wLm88Csj4SmvnTjs26SDZqyHO9m320JeJ4rDy0AyjY5 ZCmaw7cd8B1ov2wOQVQzX/Yf0DTFLWgjFxUPoefbxOL9QEAjZAP1A5g/RxQbPLJ58r2c bT3YAY7MHwHZe9XNcQL9dcSRemOGKSB+J7wm7EomHedLqkQ49YE/SO09EUfyKh0yPn+L uJqq7qIswsRwWxmn1ebotTg/F+F/LzqpCwOgkHAJiZPXrIwqMpVK+usaswcj8Q5qTfGf rWsg== Received: by 10.52.93.133 with SMTP id cu5mr13762444vdb.125.1339581673794; Wed, 13 Jun 2012 03:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 13 Jun 2012 03:00:33 -0700 (PDT) X-Originating-IP: [216.239.55.84] From: Eric Rescorla Date: Wed, 13 Jun 2012 03:00:33 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkXpJf5xznKnGdEewBL+F7NA6yIzASSUY7ZIG2oeT28HbW7c9gXw1hany2PLAXrfwBJj7zI Subject: [rtcweb] Fast restart problem statement X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 10:01:14 -0000 I feel like there are actually three different problem statements: * Web-only invisible restart: the ability for a pair of web-based applications to re-start a call upon re-load in a user-invisible way, i.e., without prompting the user to answer the call, authorize media, etc. * Web-only fast restart: Web-only invisible restart but optimized to be faster than an initial call. * Interoperable invisible restart: Like Web-only invisible restart but where one side is RTCWEB and the other side is an unmodified SIP/Jingle device. * Interoperable fast restart: like Interoperable invisible restart but optimized to be faster than an initial call. -Ekr From Markus.Isomaki@nokia.com Wed Jun 13 03:08:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643AA21F8625 for ; Wed, 13 Jun 2012 03:08:55 -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 c7UnStDbZJ3P for ; Wed, 13 Jun 2012 03:08:54 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id BB47021F8615 for ; Wed, 13 Jun 2012 03:08:54 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5DA8ka1002180; Wed, 13 Jun 2012 13:08:48 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 13:08:47 +0300 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.74]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Wed, 13 Jun 2012 12:08:47 +0200 From: To: Thread-Topic: [rtcweb] Interface switching use case and the basic needs Thread-Index: Ac1I3YCkLmPNdotdR5uuxDlimnzEOv///26A//8rRwA= Date: Wed, 13 Jun 2012 10:08:46 +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: [62.181.225.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jun 2012 10:08:47.0522 (UTC) FILETIME=[85D40820:01CD494C] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Interface switching use case and the basic needs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 10:08:55 -0000 DQoNCm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSB3cm90ZToNCj4NCj5PbiAxMiBKdW5lIDIwMTIg MTM6NTQsICA8TWFya3VzLklzb21ha2lAbm9raWEuY29tPiB3cm90ZToNCj4+IE1vc3QgdG9kYXkn cyBtb2JpbGUgZGV2aWNlcyAoc21hcnRwaG9uZXMsIHRhYmxldHMpIHdvcmsgc28sIHRoYXQgb25s eQ0KPj4gYSBzaW5nbGUgaW50ZXJmYWNlIGlzIGNvbm5lY3RlZCBhdCBhIHRpbWUuIFRoaXMgaXMg Zm9yDQo+DQo+QlRXLCB0aGlzIG9uZSBpbnRlcmZhY2UgYXQgYSB0aW1lIGJlaGF2aW91ciBpcyBy ZWFsbHkgYW5ub3lpbmcgaW4gc29tZQ0KPnNpdHVhdGlvbnMuICBXaUZpIG5ldHdvcmtzIGZyZXF1 ZW50bHkgcmVxdWlyZSBzaWduLW9uLCB3aGljaCBtZWFucyB0aGF0IHlvdQ0KPm1pZ3JhdGUgdG8g dGhlIFdpRmkgYW5kIHlvdSBzcGVuZCBhZ2VzIG11Y2tpbmcgYXJvdW5kIHdpdGggdGhlIGxvZ2lu LCBvciB5b3UNCj5oYXZlIHRvIHR1cm4gb2ZmIFdpRmkgaW4gb3JkZXIgdG8gcmVhc3NvY2lhdGUg d2l0aCB0aGUgTU1FLiAgRWl0aGVyIHdheSwgeW91DQo+aGF2ZSBhIHNpZ25pZmljYW50IGRvd24g dGltZSB3aW5kb3cuDQo+DQoNClllcywgdGhpcyBpcyBhIHdlbGwta25vd24gcHJvYmxlbS4gU29t ZSBuYcOvdmUgaW1wbGVtZW50YXRpb25zIGFyZSBoYXBweSBhZnRlciB0aGV5IGdldCBhbiBJUCBh ZGRyZXNzIGZyb20gV2ktRmkgdG8gc3dpdGNoIHRvIGl0IGFuZCBzaHV0IGRvd24gY2VsbHVsYXIu IEF0IHRoYXQgcG9pbnQgeW91IG1heSBzdGlsbCBiZSBibG9ja2VkIGJ5IGEgY2FwdGl2ZSBwb3J0 YWwgYXNraW5nIGZvciBzaWduLXVwIG9yIGFjY2VwdGluZyB0ZXJtcyBhbmQgY29uZGl0aW9ucy4g Rm9ydHVuYXRlbHkgdGhpbmdzIGFyZSBpbXByb3Zpbmcgd2l0aCBtb3JlIFdpLUZpIG5ldHdvcmtz IHVzaW5nIGF1dG9tYXRpYyBhdXRoZW50aWNhdGlvbiBsaWtlIDgwMi4xeCwgV0lTUHIsIGV0Yy4g QnV0IHRoaXMgcHJvYmxlbSB3aWxsIG5vdCBnbyBhd2F5IGluIHRoZSBuZWFyIGZ1dHVyZS4gDQoN Cj4NCj4gPiBIb3cgYWJvdXQgV2Vic29ja2V0IHByb3RvY29sPw0KPg0KPlRoYXQgZG9lc24ndCB3 b3JrLiAgVGhlIGFwcGxpY2F0aW9uIGlzIGZvcmNlZCB0byByZWNvdmVyLiAgDQoNCk9LLCB0aGF0 J3Mgd2hhdCBJIHdhcyBhZnJhaW5kIG9mLiBUaGUgcHJvYmxlbSBpcyBwdXNoZWQgdG8gZXZlcnkg c2luZ2xlIEphdmFzY3JpcHQgZGV2ZWxvcGVyIHVzaW5nIFdlYnNvY2tldHMuIA0KDQo+DQo+U3Vy ZSwgdGhlIEpTIGFwcCBnZXRzIGEgZGlzY29ubmVjdCBmcm9tIHdlYnNvY2tldHMuICBJdCBoYWQg YmV0dGVyIGRlYWwuICBUaGUNCj5mYWN0IHRoYXQgeW91IGhhdmUgaGFkIGEgc3dpdGNob3ZlciBk b2VzIHJlcXVpcmUgZWZmZWN0aXZlbHkgYSBjb21wbGV0ZQ0KPnJlYm9vdCBvZiBJQ0UsIHdoaWNo IGEgcmVhbHRpbWUgYXBwIHVsdGltYXRlbHkgbmVlZHMgdG8gZGVhbCB3aXRoIGJ5IHNpZ25hbGlu Zw0KPmNhbmRpZGF0ZXMuLi5hdCBhIG1pbmltdW0uDQo+DQoNClRoZSBtaW5pbXVtIGluZGVlZCBp cyB0aGF0IHdlIGhhdmUgdGhlIEpTIEFQSXMgaW4gcGxhY2UgdGhhdCBhbGxvd3MgdGhlIGFwcCB0 byBsZWFybiBhYm91dCB0aGUgc3dpdGNob3ZlciBhbmQgcmVjb3ZlciBmcm9tIGl0LiANCg0KPg0K PlRoaXMgaXMgY292ZXJlZCBieSB3aGF0IEVLUiBzZW50IG91dCBhbmQgSSdtIHN1cmUgdGhhdCBo ZSB3aWxsIGhhdmUgYSBwcm9wb3NhbA0KPmZvciB0aGUgQVBJIGFyb3VuZCB0aGlzLiAgSWYgaGUg ZG9lc24ndCBkbyB0aGF0IHNvb24sIEknbGwgcHJvcG9zZSBzb21ldGhpbmcgaGUNCj53b250IGxp a2UuDQo+DQoNCkdvb2QuDQoNCj4tLU1hcnRpbg0KDQpNYXJrdXMNCg== From Markus.Isomaki@nokia.com Wed Jun 13 03:09:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED2721F869F for ; Wed, 13 Jun 2012 03:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 GauLCXBGup9J for ; Wed, 13 Jun 2012 03:09:07 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6C43621F8615 for ; Wed, 13 Jun 2012 03:09:07 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5DA8mmU002194; Wed, 13 Jun 2012 13:09:04 +0300 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); Wed, 13 Jun 2012 13:08:48 +0300 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.74]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Wed, 13 Jun 2012 12:08:46 +0200 From: To: , Thread-Topic: Interface switching use case and the basic needs Thread-Index: Ac1I3YCkLmPNdotdR5uuxDlimnzEOgAMOpJQAA7G8OA= Date: Wed, 13 Jun 2012 10:08:46 +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: [62.181.225.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jun 2012 10:08:48.0106 (UTC) FILETIME=[862D24A0:01CD494C] X-Nokia-AV: Clean Subject: Re: [rtcweb] Interface switching use case and the basic needs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 10:09:08 -0000 lishitao@huawei.com wrote: > >So my question is, does this Interface switching use case support dual rad= io or >not? > >If it support, we can have a solution based on the assumption that the >browser will receive two access info, and both can be used, or If it does = not >support, I don't think the access transfer delay can be tolerated by the u= ser. >Even we have some solution in the JS and browser layer, the user may switc= h >off the call before the call has recovered. > Currently the interface switching in most OS's happens in hard-handover way= , i.e. the two interfaces are not in use at the same time. Even if the two = radios were up at the same time for a while, I believe on the IP level the = default route points only to a single interface at a time. So the browsers = and web apps should assume break-before-make handovers do happen and try to= deal with them. Having said that, it is indeed a good idea to keep the old interface up at = least for a while after the new one is activated. That gives protocols (lik= e MPTCP) and apps at least the chance to do a make-before-break transition.= There is no problem keeping up Wi-Fi and cellular interfaces at the same t= ime from the radio perspective. So, this is another scenario that browsers = and web apps (and the JS APIs) should support, in case they run on a nice p= latform able to offer it them, and the network coverage also makes it possi= ble. I don't know how complex events that APIs can convey, but this would b= e something like: "A new higher priority interface is available. The lower-= priority interface is still up for a while, but you'd better move your traf= fic/state to the new one, as the old one may be gone at any point."=20 Markus=20 From pravindran@sonusnet.com Wed Jun 13 03:46:22 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A22B21F8610 for ; Wed, 13 Jun 2012 03:46:22 -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 mT9UFdSDONke for ; Wed, 13 Jun 2012 03:46:22 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id D54D421F860F for ; Wed, 13 Jun 2012 03:46:21 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT9hvfR4Lvl59S09OqujbmSIScXID/WMF@postini.com; Wed, 13 Jun 2012 03:46:21 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 13 Jun 2012 06:46:55 -0400 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 13 Jun 2012 16:16:15 +0530 From: "Ravindran, Parthasarathi" To: Magnus Westerlund Thread-Topic: Back-to-back RTP endpoint topology in RTCWeb Thread-Index: Ac1JUcykGXpWBSzFTkSUkZFI5XNmNA== Date: Wed, 13 Jun 2012 10:46:15 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160497E6@inba-mail02.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: [rtcweb] Back-to-back RTP endpoint topology in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 10:46:22 -0000 Hi Magnus & all, I like the list of RTP topology mentioned in your interim presentation. I t= hought of asking for one more topology namely Back-to-back RTP endpoint top= ology in RTCWeb. The topology is as follows: RTP endpoint-----Back-to-back RTP Endpoint-----RTP Endpoint The reason for Back-to-back RTP Endpoint topology are 1) WebRTC RTP Endpoint to legacy RTP Endpoint (RFC 3550) interop 2) IP address hiding in WebRTC session Even though, Back-to-back RTP Endpoint *MUST* follow RTP Endpoint behavior,= the requirement will be bit more than that as the linkage with identity, I= CE consent, RTCP mandate, set of RTP draft mandates and other stuffs. Also,= the guidelines document for back-to-back RTP Endpoint shall avoid the blam= e of intermediate devices always break the architecture.=20 I'm interested in hearing whether Back-to-back RTP endpoint topology is of = interest in RTCWeb. Thanks Partha From keith.drage@alcatel-lucent.com Wed Jun 13 04:34:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3246E21F8535 for ; Wed, 13 Jun 2012 04:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.816 X-Spam-Level: X-Spam-Status: No, score=-109.816 tagged_above=-999 required=5 tests=[AWL=0.433, 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 vPz3kpzdMI-8 for ; Wed, 13 Jun 2012 04:34:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 765A421F84FC for ; Wed, 13 Jun 2012 04:34:10 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5DBUmp1020958 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 13 Jun 2012 13:34:06 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 13 Jun 2012 13:33:57 +0200 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" Date: Wed, 13 Jun 2012 13:33:56 +0200 Thread-Topic: draft-ietf-rtcweb-data-channel-00 Thread-Index: Ac1JWGq4WxR+HZEgT02z1ZMgoTYbUg== Message-ID: 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.83 Subject: [rtcweb] draft-ietf-rtcweb-data-channel-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 11:34:12 -0000 Quick question. In this document are "data stream" and "datagram stream" one and the same t= hing, or not? If yes can we harmonise the term? If no, can we define what the distinct terms mean? Keith From anant@mozilla.com Wed Jun 13 04:43:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8DD21F85C4 for ; Wed, 13 Jun 2012 04:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhwoG1cvgzcO for ; Wed, 13 Jun 2012 04:43:03 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id BEEDB21F86A1 for ; Wed, 13 Jun 2012 04:43:03 -0700 (PDT) Received: from kix.local (18.225.181.62.in-addr.dgcsystems.net [62.181.225.18]) (Authenticated sender: anarayanan@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 06EEAF260C; Wed, 13 Jun 2012 04:43:02 -0700 (PDT) Message-ID: <4FD87CC5.30407@mozilla.com> Date: Wed, 13 Jun 2012 13:43:01 +0200 From: Anant Narayanan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fast restart problem statement X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 11:43:04 -0000 On 6/13/12 12:00 PM, Eric Rescorla wrote: > I feel like there are actually three different problem statements: It looks like you listed four :) > * Web-only invisible restart: the ability for a pair of web-based applications > to re-start a call upon re-load in a user-invisible way, i.e., without prompting > the user to answer the call, authorize media, etc. > > * Web-only fast restart: Web-only invisible restart but optimized to be > faster than an initial call. Why wouldn't we always make invisible restarts as fast as possible? -Anant From goran.ap.eriksson@ericsson.com Wed Jun 13 04:45:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10AE21F85C4 for ; Wed, 13 Jun 2012 04:45:54 -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 zy-4-MYOaYEk for ; Wed, 13 Jun 2012 04:45:54 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9121F8550 for ; Wed, 13 Jun 2012 04:45:53 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-19-4fd87d702647 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DE.50.00702.07D78DF4; Wed, 13 Jun 2012 13:45:52 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.28]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 13 Jun 2012 13:45:52 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: "Markus.Isomaki@nokia.com" , "rtcweb@ietf.org" Date: Wed, 13 Jun 2012 13:45:50 +0200 Thread-Topic: Interface switching use case and the basic needs Thread-Index: Ac1I3YCkLmPNdotdR5uuxDlimnzEOgAMOpJQAA7G8OAAA7zIcA== Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvrW5B7Q1/g1OT9CzO/13EZrH2Xzu7 A5PHkiU/mTzu3rrEFMAUxWWTkpqTWZZapG+XwJUx//YiloJLwhUT509nbWB8xt/FyMkhIWAi 8frcGRYIW0ziwr31bF2MXBxCAqcYJWauuMgK4SxglPh54SITSBWbgLfEtBVngRIcHCICCRK3 j4uBhFkEVCWWzH7PBmILC9hK3Ly/mxnEFhGwk/i9bTOU7SSxbslKRhCbVyBcYkr7Aqj5bxkl Dja1gF3BKRAm8ebZYrBdjAKyEve/3wOLMwuIS9x6Mp8J4lIBiSV7zjND2KISLx//Y4Wol5E4 teg/K0S9nsSNqVPYIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjEK5yZm 5qSXm+ulFmUmFxfn5+kVp25iBEbJwS2/DXYwbrovdohRmoNFSZxXT3W/v5BAemJJanZqakFq UXxRaU5q8SFGJg5OqQbGNfdk2220e5fmvlz+oDfKJeXrt2n95f/+WFbaxS4wbPJj+2p22LJ1 Tc3iE4Y7VoQtuZUfHfC1t3Xx/qWvWnYuNL+ssq3mxK3jee1PvnxYumGiEY/l45nJqZuiExpf qVn4LL698PHXLRGLWPZnHmo7G/BC8+HHnBdl/XrMF7JzNn3ZKyDywUG1V4mlOCPRUIu5qDgR AOXnTWxgAgAA Subject: Re: [rtcweb] Interface switching use case and the basic needs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 11:45:55 -0000 =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com > Sent: den 13 juni 2012 12:09 > To: lishitao@huawei.com; rtcweb@ietf.org > Subject: Re: [rtcweb] Interface switching use case and the basic needs >=20 >=20 > lishitao@huawei.com wrote: > > > >So my question is, does this Interface switching use case=20 > support dual=20 > >radio or not? > > > >If it support, we can have a solution based on the=20 > assumption that the=20 > >browser will receive two access info, and both can be used, or If it=20 > >does not support, I don't think the access transfer delay=20 > can be tolerated by the user. > >Even we have some solution in the JS and browser layer, the user may=20 > >switch off the call before the call has recovered. > > >=20 > Currently the interface switching in most OS's happens in=20 > hard-handover way, i.e. the two interfaces are not in use at=20 > the same time. Even if the two radios were up at the same=20 > time for a while, I believe on the IP level the default route=20 > points only to a single interface at a time. So the browsers=20 > and web apps should assume break-before-make handovers do=20 > happen and try to deal with them. >=20 > Having said that, it is indeed a good idea to keep the old=20 > interface up at least for a while after the new one is=20 > activated. That gives protocols (like MPTCP) and apps at=20 > least the chance to do a make-before-break transition. There=20 > is no problem keeping up Wi-Fi and cellular interfaces at the=20 > same time from the radio perspective. So, this is another=20 > scenario that browsers and web apps (and the JS APIs) should=20 > support, in case they run on a nice platform able to offer it=20 > them, and the network coverage also makes it possible. I=20 > don't know how complex events that APIs can convey, but this=20 > would be something like: "A new higher priority interface is=20 > available. The lower-priority interface is still up for a=20 > while, but you'd better move your traffic/state to the new=20 > one, as the old one may be gone at any point."=20 Who is setting the "priority" of the interface? Should not the web app have= a say whether the traffic should be kept on a particular interface or not? >=20 > Markus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From ekr@rtfm.com Wed Jun 13 04:46:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C27621F86A7 for ; Wed, 13 Jun 2012 04:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 OHLtLC9GwrMR for ; Wed, 13 Jun 2012 04:46:10 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 897D421F8550 for ; Wed, 13 Jun 2012 04:46:10 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so377626vbb.31 for ; Wed, 13 Jun 2012 04:46:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=mTC5QLyFD/pqRLfTDkLT7ms6MUqJ0OxYiprexo8rKa4=; b=kM1xF9W1Dt30yDqljqyTKRRm/jYFfRy7B3aPNU/ERhJ+XKvRnMdohIGnfPW8IwjSML /H3bFb98DxAjJbjcoHD7bY//Nqr5ttmwLt68X7jKaSFMfWWxxmwh16TbRwJqcloMDHRV xGV8khj/t5T48atq4vovawIIHdXFE89q7VYL1m60DpTpisTweodhpdHLJDh8XoPjL/kz y0/uxyRL/PrZvwFYkgg1Z29elia+pBMsNpyThKLB206pGHjHu8J4rWkkuLg0pF3cmElO Tq/d9PWmdUvwk7fXh1JMHHMyv4AwczzN9ugP1acVnvHQNF+H7LE2ufIlXhHOJASCHNPR 2kfA== Received: by 10.52.88.170 with SMTP id bh10mr13871473vdb.11.1339587968179; Wed, 13 Jun 2012 04:46:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 13 Jun 2012 04:45:27 -0700 (PDT) X-Originating-IP: [216.239.55.84] In-Reply-To: <4FD87CC5.30407@mozilla.com> References: <4FD87CC5.30407@mozilla.com> From: Eric Rescorla Date: Wed, 13 Jun 2012 04:45:27 -0700 Message-ID: To: Anant Narayanan Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlwN7N9O1mm3wRbNc817gnYzjIUV1odmbIdANRrkQ56xez2Lu5rwSacbExlDwheWyE/rBwv Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fast restart problem statement X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 11:46:11 -0000 On Wed, Jun 13, 2012 at 4:43 AM, Anant Narayanan wrote: > On 6/13/12 12:00 PM, Eric Rescorla wrote: >> >> I feel like there are actually three different problem statements: > > > It looks like you listed four :) > > >> * Web-only invisible restart: the ability for a pair of web-based >> applications >> to re-start a call upon re-load in a user-invisible way, i.e., without >> prompting >> the user to answer the call, authorize media, etc. >> >> * Web-only fast restart: Web-only invisible restart but optimized to be >> faster than an initial call. > > > Why wouldn't we always make invisible restarts as fast as possible? If it required defining new protocol mechanisms, for instance. -Ekr From dburnett@voxeo.com Wed Jun 13 05:10:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F7621F863B for ; Wed, 13 Jun 2012 05:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7WoHy8kzlJe for ; Wed, 13 Jun 2012 05:10:34 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4C25D21F855F for ; Wed, 13 Jun 2012 05:10:34 -0700 (PDT) Received: from [62.181.225.18] (account dburnett@voxeo.com HELO [10.59.1.50]) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 113508832; Wed, 13 Jun 2012 12:10:33 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dan Burnett In-Reply-To: Date: Wed, 13 Jun 2012 08:10:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] New draft-burnett-rtcweb-constraints-registry-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 12:10:35 -0000 I defer to Cullen (as a chair of this group) on this issue. I don't = personally care one way or the other. -- dan On Mar 2, 2012, at 8:14 PM, DRAGE, Keith (Keith) wrote: > Pedantic process issue. >=20 > Do we need a proposed standard to create an IANA registry which only = needs expert review to add a value, or will informational suffice? >=20 > Keith >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >> Of Dan Burnett >> Sent: 02 March 2012 21:18 >> To: >> Subject: [rtcweb] New draft-burnett-rtcweb-constraints-registry-00 >>=20 >> Group, >>=20 >> I have just submitted a new draft [1] to create a registry for HTML = Media >> constraints for use by the W3C getusermedia and WebRTC specs. An = early >> email proposal on this subject (not the registry, but the use of it) = is >> available [2] for background. I will be updating that with a fuller >> proposal that incorporates changes discussed on the Media Capture = Task >> Force teleconference [3], so don't be surprised if you notice slight >> differences in the syntax in the registry from what was proposed in = email >> [2]. >>=20 >> I don't know how much discussion will happen on this list for this = draft, >> but at the least this group should be aware of the W3C need for it. >>=20 >> -- dan >>=20 >> [1] = https://datatracker.ietf.org/doc/draft-burnett-rtcweb-constraints- >> registry/ >> [2] = http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0198.html >> [3] = http://lists.w3.org/Archives/Public/public-media-capture/2012Feb/att- >> 0053/minutes-2012-02-28.html >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Wed Jun 13 05:10:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E48321F858A for ; Wed, 13 Jun 2012 05:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.311 X-Spam-Level: X-Spam-Status: No, score=-101.311 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgWF1kLLuVvK for ; Wed, 13 Jun 2012 05:10:55 -0700 (PDT) Received: from blu0-omc1-s21.blu0.hotmail.com (blu0-omc1-s21.blu0.hotmail.com [65.55.116.32]) by ietfa.amsl.com (Postfix) with ESMTP id DC2FB21F855F for ; Wed, 13 Jun 2012 05:10:54 -0700 (PDT) Received: from BLU169-W44 ([65.55.116.7]) by blu0-omc1-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 05:10:54 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_923c3bfe-bc9d-4d61-9f86-3fff37129336_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: , Date: Wed, 13 Jun 2012 05:10:54 -0700 Importance: Normal In-Reply-To: <4FD83FD0.3070806@alvestrand.no> References: <4FD82793.9010506@mozilla.com>,<4FD83FD0.3070806@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jun 2012 12:10:54.0515 (UTC) FILETIME=[950E7030:01CD495D] Subject: Re: [rtcweb] RTP clock rates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 12:10:55 -0000 --_923c3bfe-bc9d-4d61-9f86-3fff37129336_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said:=20 > To be more precise: I suggested that we should incorporate by reference=20 > the advice in draft-ietf-avtext-multiple-clock-rates-05: >=20 > 4.1. RTP Sender (with RTCP) >=20 > An RTP Sender with RTCP turned on MUST use a different SSRC for each > different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST > be used if the clock rate switches back to a value already seen in > the RTP stream. [BA] Yes=2C I think this makes sense.=20 = --_923c3bfe-bc9d-4d61-9f86-3fff37129336_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald said:

>=3B To be more precise: I suggested that we sh= ould incorporate by reference
>=3B the advice in draft-ietf-avtext-mu= ltiple-clock-rates-05:
>=3B
>=3B 4.1. RTP Sender (with RTCP)>=3B
>=3B An RTP Sender with RTCP turned on MUST use a differe= nt SSRC for each
>=3B different clock rate. An RTCP BYE MUST be s= ent and a new SSRC MUST
>=3B be used if the clock rate switches ba= ck to a value already seen in
>=3B the RTP stream.

[BA] Yes= =2C I think this makes sense.
= --_923c3bfe-bc9d-4d61-9f86-3fff37129336_-- From Markus.Isomaki@nokia.com Wed Jun 13 05:35:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C6B21F849B for ; Wed, 13 Jun 2012 05:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 zrXgn+QXAZM5 for ; Wed, 13 Jun 2012 05:35:34 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDF521F84D5 for ; Wed, 13 Jun 2012 05:35:34 -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 q5DCZUqY007081; Wed, 13 Jun 2012 15:35:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 15:35:29 +0300 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.74]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Wed, 13 Jun 2012 14:35:28 +0200 From: To: , Thread-Topic: Interface switching use case and the basic needs Thread-Index: Ac1I3YCkLmPNdotdR5uuxDlimnzEOgAMOpJQAA7G8OAAA7zIcAABpeMA Date: Wed, 13 Jun 2012 12:35:28 +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: [62.181.225.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jun 2012 12:35:29.0825 (UTC) FILETIME=[0468E110:01CD4961] X-Nokia-AV: Clean Subject: Re: [rtcweb] Interface switching use case and the basic needs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 12:35:35 -0000 Hi, goran.ap.eriksson@ericsson.com wrote: >>"A new higher priority interface is available. The >> lower-priority interface is still up for a while, but you'd better >> move your traffic/state to the new one, as the old one may be gone at >> any point." > >Who is setting the "priority" of the interface? Should not the web app hav= e a >say whether the traffic should be kept on a particular interface or not? > This is usually a system-wide policy enforced by the connection manager. In= dividual apps can't influence it. We do have a capability in Symbian by whi= ch the apps can set preferences, but it has not been used very much - app d= evelopers have no clue about interfaces. So far it has been quite a strict = requirement that we want to keep only one radio interface active at a time = to save power. The apps will just have to live with that. There can be some special apps like IMS and MMS that have their own policie= s, mainly because they don't work over Wi-Fi (no security, no NAT traversal= , accounting is based on IP address etc. reasons). But normal apps have ver= y limited powers. Web apps probably the worst since they are additionally r= estricted by the web runtime's capabilities. =20 Markus From bernard_aboba@hotmail.com Wed Jun 13 06:14:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A9E21F85E7 for ; Wed, 13 Jun 2012 06:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.005 X-Spam-Level: X-Spam-Status: No, score=-102.005 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP5iQ0XAy0yv for ; Wed, 13 Jun 2012 06:14:50 -0700 (PDT) Received: from blu0-omc1-s14.blu0.hotmail.com (blu0-omc1-s14.blu0.hotmail.com [65.55.116.25]) by ietfa.amsl.com (Postfix) with ESMTP id 87DC421F8518 for ; Wed, 13 Jun 2012 06:14:50 -0700 (PDT) Received: from BLU169-W109 ([65.55.116.9]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 06:14:50 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_5ea74a17-8298-4f64-9209-a5d12a244e29_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: , Date: Wed, 13 Jun 2012 06:14:49 -0700 Importance: Normal In-Reply-To: <4FD84C66.2030806@alvestrand.no> References: <4FD7069C.8080803@ifi.uio.no>, <4FD707AD.1040601@mozilla.com>, <4FD70E1D.10509@ifi.uio.no>, <4FD84C66.2030806@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jun 2012 13:14:50.0109 (UTC) FILETIME=[833FA2D0:01CD4966] Subject: Re: [rtcweb] Question about usage of data traffic X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 13:14:51 -0000 --_5ea74a17-8298-4f64-9209-a5d12a244e29_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The reason for the initial data use cases was that we wanted to focus on= =20 > the stuff that *couldn't* be done by bouncing data off a server=3B=20 > non-time-sensitive bulk file transfer can certainly be done via a=20 > server=2C even though that may not be optimal. > > That said=2C we've always expected that once the data transfer capability= =20 > is in place=2C we'll have plenty of people wanting to use it in=20 > "unexpected" ways. > > The important RTCWEB-specific requirement from the file transfer use=20 > case is probably that IF file transfer is done in a peer-to-peer=20 > fashion=2C within the RTCWEB context=2C it MUST be able to run without=20 > degrading the quality of the real time media. [BA] We need to be careful about the definition of "degrade". If the goal= is to support the best video quality=20 possible (e.g. highest frame rate/quality/resolution supportable on the pat= h)=2C then starting a file transfer on=20 the same path may require the video to reduce bandwidth usage. This by its= elf does not seem problematic.=20 However=2C it would be problematic if the file transfer builds a queue that= results in unacceptable latency. A large file transfer over TCP via the server will tend to do this -- but a f= ile transfer handled over the data channel should not.=20 =20 = --_5ea74a17-8298-4f64-9209-a5d12a244e29_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B The reason for the initial data use cases = was that we wanted to focus on
>=3B the stuff that *couldn't* be done= by bouncing data off a server=3B
>=3B non-time-sensitive bulk file t= ransfer can certainly be done via a
>=3B server=2C even though that m= ay not be optimal.
>=3B
>=3B That said=2C we've always expected t= hat once the data transfer capability
>=3B is in place=2C we'll have = plenty of people wanting to use it in
>=3B "unexpected" ways.
>= =3B
>=3B The important RTCWEB-specific requirement from the file trans= fer use
>=3B case is probably that IF file transfer is done in a peer= -to-peer
>=3B fashion=2C within the RTCWEB context=2C it MUST be able= to run without
>=3B degrading the quality of the real time media.
[BA] We need to be careful about the definition of "degrade". =3B&= nbsp=3B If the goal is to support the best video quality
possible (e.g.= highest frame rate/quality/resolution supportable on the path)=2C then sta= rting a file transfer on
the same path may require the video to reduce = bandwidth usage. =3B This by itself does not seem problematic.

= However=2C it would be problematic if the file transfer builds a queue that= results in unacceptable latency. A
large file transfer over TCP via the= server will tend to do this -- but a file transfer handled over the data c= hannel
should not.

 =3B
= --_5ea74a17-8298-4f64-9209-a5d12a244e29_-- From stefan.lk.hakansson@ericsson.com Wed Jun 13 06:36:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55E821F852A for ; Wed, 13 Jun 2012 06:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_41=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 wca6XPOi-cYF for ; Wed, 13 Jun 2012 06:36:54 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E18B21F8525 for ; Wed, 13 Jun 2012 06:36:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-7f-4fd89774ca44 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 21.70.28636.47798DF4; Wed, 13 Jun 2012 15:36:52 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Wed, 13 Jun 2012 15:36:52 +0200 Message-ID: <4FD89773.3090506@ericsson.com> Date: Wed, 13 Jun 2012 15:36:51 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+JvrW7J9Bv+Bp9/G1ms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCeT25kKdstXXNh1gamBcY9kFyMnh4SAicSvdTOYIGwxiQv3 1rN1MXJxCAmcYpSYteUhC4SznFHi8oc2VpAqXgFtia2/D7KB2CwCqhJ/Fx8Di7MJ2Eis7Z4C NImDQ1QgTGL1Aw2IckGJkzOfsIDYIgLCEltf9YKVCAOV/OgRgBh/hlli1e8HYDWcAr4Siy7P YAaxmQVsJS7Muc4CYctLbH87BywuJKAr8e71PdYJjAKzkKyYhaRlFpKWBYzMqxiFcxMzc9LL DfVSizKTi4vz8/SKUzcxAsPv4JbfujsYT50TOcQozcGiJM7LlbTfX0ggPbEkNTs1tSC1KL6o NCe1+BAjEwenVANj+8U5bQ8sE65MmbdkYu+6Z7HXQ3Rz7y5USrS57TvB+MulNl6nHIapsp/1 v9d56rXeXr9KcLJpbe0/i5/hhQxM9y8teNZ+9rwsn6tBltzjLbeKOnosW3QTFn6c2xD7dF8f 1y8rISdW5VK1gA/+Bgf+etaVrj0gdKRgVuW+DRP5xFx5uW6r3zNRYinOSDTUYi4qTgQA6g9d KA0CAAA= Subject: Re: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 13:36:55 -0000 On 06/10/2012 10:03 PM, Hutton, Andrew wrote: > Hi Ted, > > See below. > > Regards Andy > >> -----Original Message----- From: Ted Hardie >> [mailto:ted.ietf@gmail.com] Sent: 10 June 2012 18:48 To: Hutton, >> Andrew Cc: rtcweb@ietf.org Subject: Re: [rtcweb] More Comments on >> draft-ietf-rtcweb-use-cases-and- requirements-07 >> >> On Sun, Jun 10, 2012 at 5:33 PM, Hutton, Andrew >> wrote: >>> Hi, >>> >> >>> Section 4.1.1.1 (Simple Video Communication Service) contains >>> the >> statement "Each user can also pause sending of media (audio, video, >> or both) and mute incoming media". I think this and the >> associated requirements need some clarification for example whether >> the requirement is to control the direction of the media and >> therefore requires the generation of a new SDP offer with for >> example a direction of "recvonly/inactive". >> >> Howdy, >> >> As a clarifying question, are you thinking that it is not clear >> because non-signaling methods could achieve some of these? That >> is "muting" incoming media could also be accomplished entirely >> receive side, by simply not rendering it? >> > > Yes I guess so it is not clear whether the use case results in a > local action in the browser or it whether it impacts the media and > SDP. I want to make sure that it is possible to control the media > direction in SDP (sendrecv/recvonly/sendonly/inactive) and have the > browser behave appropriately. This is my personal understanding: - the API (and this part has been there for a long time) allows the application to disable/enable individual tracks of MediaStreams - So say you have a MediaStream (one audio track, one video track in this example) that is rendered using a video element; disabling audio would lead to silence, disabling video to that the video stops - The question is: what should happen if the MediaStream is connected to a PeerConnection and sent to a peer? - using recvonly does not seem appropriate as that would stop all ssrc:s belonging to the same m-line - and the app only disabled one - one option could be to simply stop sending the RTP packets for this track. I don't know how reliable that would be - I think there has been proposals signaling this in SDP or in RTCP, but I don't think there was ever any conclusion For the other part, muting incoming media, this is simple: the app (at receiving browser) could just disable the tracks it wants in the incoming MediaStreams. A related question is if this should be signaled back to the sender (so it could stop sending). This is essentially a question of efficiency/optimization, and nothing stops the app from signaling that now using an app specific protocol (perhaps carried over the data channel), but perhaps this should be brought into SDP or RTCP. > > >> regards, >> >> Ted >> >> The only associated requirement seems to be A8 but this does not >> help clarify what is meant by "pause" in the use case. It needs to >> be clarified whether the pause/resume/mute are actions within the >> browser or are actions which result in notifications to the remote >> user. >>> >>> Maybe we could add a use case which involves controlling the >> direction of multiple streams to emulate switching between >> different users in a multiparty call scenario. >>> >>> >>> The statement "It is essential that the communication cannot be >> eavesdropped" appears in all use cases so could be moved to section >> 4.1 but I think it needs to be reworded in terms of the media >> always being encrypted as I don't like the term "eavesdropped" >> which is not defined. >>> >>> Regards Andy >>> >>> >>> >>> _______________________________________________ rtcweb mailing >>> list rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From salvatore.loreto@ericsson.com Wed Jun 13 07:36:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA121F869A for ; Wed, 13 Jun 2012 07:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 q7jE0jhHBCfg for ; Wed, 13 Jun 2012 07:36:46 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 92B2E21F8699 for ; Wed, 13 Jun 2012 07:36:45 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-85-4fd8a57cbe63 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 18.05.11869.C75A8DF4; Wed, 13 Jun 2012 16:36:44 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Wed, 13 Jun 2012 16:36:43 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AE5DE22EA for ; Wed, 13 Jun 2012 17:36:43 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C17DC531D5 for ; Wed, 13 Jun 2012 17:36:43 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 80A5F53078 for ; Wed, 13 Jun 2012 17:36:43 +0300 (EEST) Message-ID: <4FD8A57B.1060708@ericsson.com> Date: Wed, 13 Jun 2012 16:36:43 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+JvrW7N0hv+Bu9mC1is/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujA/T57MXfGauePl0JnsDYy9zFyMnh4SAicTeiUfYIWwxiQv3 1rN1MXJxCAmcYpSYu/UXlLOBUaL/8EQWCOcio8TshwuZIZwjjBKvVnxignDOMkpc2TCZFWQY r4C2xIdDX8FsFgFVibNHf7CB2GwCZhLPH24BWy4qkCzRe76BGaJeUOLkzCcsILaIgLDE1le9 TCC2sIC5xJyLC8B6hQRiJTYuOw0W5xSIk9j9+ixYnFnAVuLCnOssELa8xPa3c6CeU5O4em4T M0SvlkTv2U6mCYwis5Csm4WkfRaS9gWMzKsYhXMTM3PSy430Uosyk4uL8/P0ilM3MQLD/OCW 36o7GO+cEznEKM3BoiTOa711j7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRqa1E6v4Pp8p iNYotVi3tX1X3tZT3PZ/W9bM2qTzr5eT/ev2vS0lZxgfnF1Wp1G94LPP5l2TQkO+rWTQbssp bF6/yvkKU3TeMxbLpX2Gj6tOzTd66tBSvjHN/OjDkjuzDHI0JoSf05+y+OTpBwt1HzXPPdTT OoV/7rGTBtYGXx/rff7p++GMX78SS3FGoqEWc1FxIgCpROWbQQIAAA== Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 14:36:46 -0000 On 6/13/12 1:33 PM, DRAGE, Keith (Keith) wrote: > Quick question. > > In this document are "data stream" and "datagram stream" one and the same thing, or not? > > If yes can we harmonise the term? thanks we are going to harmonies the term in the next 01 version Salvatore > > If no, can we define what the distinct terms mean? > > Keith > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Wed Jun 13 11:34:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEEE11E8083 for ; Wed, 13 Jun 2012 11:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVsOBONDyQSw for ; Wed, 13 Jun 2012 11:34:58 -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 00CA711E807F for ; Wed, 13 Jun 2012 11:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4332; q=dns/txt; s=iport; t=1339612498; x=1340822098; h=from:to:subject:date:message-id:mime-version; bh=L7xVuPdl/qfMBdtW07i8xmXz0HKBDwqKXwjEQM/LzaQ=; b=CHUManrlxC/IjMvlFJIcHsx7qMgrJ/4+mjNbLx1vCzVKIHpBnFGCBKhf HRLcvzvpU7CxecvVaQpnrq/FLVeQidAP+eXS6eSsK5NfB0wTrb/GVSQNn nC2IfEDhdjLOMA+14Se/UifnUX9vDF8QbwVGY7Bjsq86TOC9k9hSGZA+A o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMnc2E+tJXHA/2dsb2JhbABFgkWyfIEHghoBBBIBGl4BDB5WJgEEGxqHaZkIgSigApBiYAOjN4FmgmA X-IronPort-AV: E=Sophos;i="4.75,765,1330905600"; d="scan'208,217";a="92184711" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 13 Jun 2012 18:34:57 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5DIYvlu031362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Jun 2012 18:34:57 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Wed, 13 Jun 2012 13:34:57 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "rtcweb@ietf.org" Thread-Topic: Combining consent freshness and liveness Thread-Index: Ac1JkzpdFk+35VOXSv+gj0o2hfmGcA== Date: Wed, 13 Jun 2012 18:34:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.81.57] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18968.000 x-tm-as-result: No--31.226300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2012792EBxmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: [rtcweb] Combining consent freshness and liveness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:34:59 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012792EBxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Taking a closer look at the "Combined Consent/Liveness Proposal II" (slide = 16) from Eric's RTCWeb security presentation today, it seems to align close= ly with what said in WebEx -- determining consent freshness must be under t= he browser control and determining session liveness must be under the appli= cation control. If I understood correctly, the proposal is to have the cons= ent timer Tc under the browser control and the packet receipt timer Tr unde= r the application control. So, I full support it. I can work with Eric to incorporate it into draft-muthu-behave-consent-fres= hness. However, I would like us to reach a (rough) consensus on whether the= STUN transactions for consent freshness / liveness should include or omit = the message integrity and thereby use the STUN Binding requests/responses o= r a new method. Muthu --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012792EBxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Taking a closer look at the "Combined Consent/Livenes= s Proposal II" (slide 16) from Eric's RTCWeb security presentation tod= ay, it seems to align closely with what said in WebEx -- determining consent freshness must be under the browser control and determ= ining session liveness must be under the application control. If I understo= od correctly, the proposal is to have the consent timer Tc under the browse= r control and the packet receipt timer Tr under the application control. So, I full support it.<= /span>

 

I can work with Eric to incorporate it into draft-muthu-be= have-consent-freshness. However, I would like us to reach a (rough) consens= us on whether the STUN transactions for consent freshness / liveness should include or omit the message integrity and ther= eby use the STUN Binding requests/responses or a new method.

 

Muthu

--_000_E721D8C6A2E1544DB2DEBC313AF54DE2012792EBxmbrcdx02ciscoc_-- From lishitao@huawei.com Wed Jun 13 18:14:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A6211E80E8 for ; Wed, 13 Jun 2012 18:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.134 X-Spam-Level: X-Spam-Status: No, score=-0.134 tagged_above=-999 required=5 tests=[AWL=5.413, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMQN71ZTJ6MD for ; Wed, 13 Jun 2012 18:14:31 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D705511E80C2 for ; Wed, 13 Jun 2012 18:14:30 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGW93639; Wed, 13 Jun 2012 21:14:30 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 18:12:55 -0700 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 18:12:59 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.45]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Thu, 14 Jun 2012 09:12:48 +0800 From: Lishitao To: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= , "Markus.Isomaki@nokia.com" , "rtcweb@ietf.org" Thread-Topic: Interface switching use case and the basic needs Thread-Index: Ac1I3YCkLmPNdotdR5uuxDlimnzEOgAMOpJQAA7G8OAAA7zIcAAce4Cw Date: Thu, 14 Jun 2012 01:12:47 +0000 Message-ID: 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.73.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [rtcweb] =?utf-8?b?562U5aSNOiBJbnRlcmZhY2Ugc3dpdGNoaW5nIHVzZSBj?= =?utf-8?q?ase_and_the_basic_needs?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 01:14:31 -0000 DQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IHJ0Y3dlYi1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBHP3JhbiBFcmlrc3Nv biBBUA0K5Y+R6YCB5pe26Ze0OiAyMDEy5bm0NuaciDEz5pelIDE5OjQ2DQrmlLbku7bkuro6IE1h cmt1cy5Jc29tYWtpQG5va2lhLmNvbTsgcnRjd2ViQGlldGYub3JnDQrkuLvpopg6IFJlOiBbcnRj d2ViXSBJbnRlcmZhY2Ugc3dpdGNoaW5nIHVzZSBjYXNlIGFuZCB0aGUgYmFzaWMgbmVlZHMNCg0K IA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnIA0KPiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTWFya3VzLklzb21ha2lAbm9raWEuY29tDQo+IFNlbnQ6IGRlbiAxMyBqdW5pIDIwMTIgMTI6 MDkNCj4gVG86IGxpc2hpdGFvQGh1YXdlaS5jb207IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gSW50ZXJmYWNlIHN3aXRjaGluZyB1c2UgY2FzZSBhbmQgdGhlIGJhc2lj IG5lZWRzDQo+IA0KPiANCj4gbGlzaGl0YW9AaHVhd2VpLmNvbSB3cm90ZToNCj4gPg0KPiA+U28g bXkgcXVlc3Rpb24gaXMsIGRvZXMgdGhpcyBJbnRlcmZhY2Ugc3dpdGNoaW5nIHVzZSBjYXNlIA0K PiBzdXBwb3J0IGR1YWwgDQo+ID5yYWRpbyBvciBub3Q/DQo+ID4NCj4gPklmIGl0IHN1cHBvcnQs IHdlIGNhbiBoYXZlIGEgc29sdXRpb24gYmFzZWQgb24gdGhlIA0KPiBhc3N1bXB0aW9uIHRoYXQg dGhlIA0KPiA+YnJvd3NlciB3aWxsIHJlY2VpdmUgdHdvIGFjY2VzcyBpbmZvLCBhbmQgYm90aCBj YW4gYmUgdXNlZCwgb3IgSWYgaXQgDQo+ID5kb2VzIG5vdCBzdXBwb3J0LCBJIGRvbid0IHRoaW5r IHRoZSBhY2Nlc3MgdHJhbnNmZXIgZGVsYXkgDQo+IGNhbiBiZSB0b2xlcmF0ZWQgYnkgdGhlIHVz ZXIuDQo+ID5FdmVuIHdlIGhhdmUgc29tZSBzb2x1dGlvbiBpbiB0aGUgSlMgYW5kIGJyb3dzZXIg bGF5ZXIsIHRoZSB1c2VyIG1heSANCj4gPnN3aXRjaCBvZmYgdGhlIGNhbGwgYmVmb3JlIHRoZSBj YWxsIGhhcyByZWNvdmVyZWQuDQo+ID4NCj4gDQo+IEN1cnJlbnRseSB0aGUgaW50ZXJmYWNlIHN3 aXRjaGluZyBpbiBtb3N0IE9TJ3MgaGFwcGVucyBpbiANCj4gaGFyZC1oYW5kb3ZlciB3YXksIGku ZS4gdGhlIHR3byBpbnRlcmZhY2VzIGFyZSBub3QgaW4gdXNlIGF0IA0KPiB0aGUgc2FtZSB0aW1l LiBFdmVuIGlmIHRoZSB0d28gcmFkaW9zIHdlcmUgdXAgYXQgdGhlIHNhbWUgDQo+IHRpbWUgZm9y IGEgd2hpbGUsIEkgYmVsaWV2ZSBvbiB0aGUgSVAgbGV2ZWwgdGhlIGRlZmF1bHQgcm91dGUgDQo+ IHBvaW50cyBvbmx5IHRvIGEgc2luZ2xlIGludGVyZmFjZSBhdCBhIHRpbWUuIFNvIHRoZSBicm93 c2VycyANCj4gYW5kIHdlYiBhcHBzIHNob3VsZCBhc3N1bWUgYnJlYWstYmVmb3JlLW1ha2UgaGFu ZG92ZXJzIGRvIA0KPiBoYXBwZW4gYW5kIHRyeSB0byBkZWFsIHdpdGggdGhlbS4NCj4gDQo+IEhh dmluZyBzYWlkIHRoYXQsIGl0IGlzIGluZGVlZCBhIGdvb2QgaWRlYSB0byBrZWVwIHRoZSBvbGQg DQo+IGludGVyZmFjZSB1cCBhdCBsZWFzdCBmb3IgYSB3aGlsZSBhZnRlciB0aGUgbmV3IG9uZSBp cyANCj4gYWN0aXZhdGVkLiBUaGF0IGdpdmVzIHByb3RvY29scyAobGlrZSBNUFRDUCkgYW5kIGFw cHMgYXQgDQo+IGxlYXN0IHRoZSBjaGFuY2UgdG8gZG8gYSBtYWtlLWJlZm9yZS1icmVhayB0cmFu c2l0aW9uLiBUaGVyZSANCj4gaXMgbm8gcHJvYmxlbSBrZWVwaW5nIHVwIFdpLUZpIGFuZCBjZWxs dWxhciBpbnRlcmZhY2VzIGF0IHRoZSANCj4gc2FtZSB0aW1lIGZyb20gdGhlIHJhZGlvIHBlcnNw ZWN0aXZlLiBTbywgdGhpcyBpcyBhbm90aGVyIA0KPiBzY2VuYXJpbyB0aGF0IGJyb3dzZXJzIGFu ZCB3ZWIgYXBwcyAoYW5kIHRoZSBKUyBBUElzKSBzaG91bGQgDQo+IHN1cHBvcnQsIGluIGNhc2Ug dGhleSBydW4gb24gYSBuaWNlIHBsYXRmb3JtIGFibGUgdG8gb2ZmZXIgaXQgDQo+IHRoZW0sIGFu ZCB0aGUgbmV0d29yayBjb3ZlcmFnZSBhbHNvIG1ha2VzIGl0IHBvc3NpYmxlLiBJIA0KPiBkb24n dCBrbm93IGhvdyBjb21wbGV4IGV2ZW50cyB0aGF0IEFQSXMgY2FuIGNvbnZleSwgYnV0IHRoaXMg DQo+IHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlOiAiQSBuZXcgaGlnaGVyIHByaW9yaXR5IGludGVy ZmFjZSBpcyANCj4gYXZhaWxhYmxlLiBUaGUgbG93ZXItcHJpb3JpdHkgaW50ZXJmYWNlIGlzIHN0 aWxsIHVwIGZvciBhIA0KPiB3aGlsZSwgYnV0IHlvdSdkIGJldHRlciBtb3ZlIHlvdXIgdHJhZmZp Yy9zdGF0ZSB0byB0aGUgbmV3IA0KPiBvbmUsIGFzIHRoZSBvbGQgb25lIG1heSBiZSBnb25lIGF0 IGFueSBwb2ludC4iIA0KDQpXaG8gaXMgc2V0dGluZyB0aGUgInByaW9yaXR5IiBvZiB0aGUgaW50 ZXJmYWNlPyBTaG91bGQgbm90IHRoZSB3ZWIgYXBwIGhhdmUgYSBzYXkgd2hldGhlciB0aGUgdHJh ZmZpYw0Kc2hvdWxkIGJlIGtlcHQgb24gYSBwYXJ0aWN1bGFyIGludGVyZmFjZSBvciBub3Q/DQoN CiAgSSB0aGluayB0aGUgT1Mgc2hvdWxkIHNldCB0aGUgInByaW9yaXR5Iiwgb25seSB0aGUgT1Mg a25vdyB3aGljaCBpbnRlcmZhY2UgaGFzIHRoZSBiZXR0ZXIgc2lnbmFsLiBUaGUgYXBwIGNhbiBn ZXQgc3VjaCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBicm93c2VyLCBhbmQgdHJpZ2dlciB0aGUgdHJh bnNmZXIuDQo+IA0KPiBNYXJrdXMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4gDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxp bmcgbGlzdA0KcnRjd2ViQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0K From harald@alvestrand.no Wed Jun 13 23:29:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846F021F8672 for ; Wed, 13 Jun 2012 23:29:40 -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 eMpOXzZMAfY6 for ; Wed, 13 Jun 2012 23:29:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A9F2221F8671 for ; Wed, 13 Jun 2012 23:29:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD3ED39E154 for ; Thu, 14 Jun 2012 08:30:03 +0200 (CEST) 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 iwU6NltmoQOk for ; Thu, 14 Jun 2012 08:30:03 +0200 (CEST) Received: from [192.168.11.107] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1434339E058 for ; Thu, 14 Jun 2012 08:30:03 +0200 (CEST) Message-ID: <4FD984D5.80207@alvestrand.no> Date: Thu, 14 Jun 2012 08:29:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040900020809090203040900" Subject: Re: [rtcweb] Combining consent freshness and liveness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 06:29:40 -0000 This is a multi-part message in MIME format. --------------040900020809090203040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/13/2012 08:34 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: > > Taking a closer look at the "Combined Consent/Liveness Proposal II" > (slide 16) from Eric's RTCWeb security presentation today, it seems to > align closely with what said in WebEx -- determining consent freshness > must be under the browser control and determining session liveness > must be under the application control. If I understood correctly, the > proposal is to have the consent timer Tc under the browser control and > the packet receipt timer Tr under the application control. So, I full > support it. > To the extent that I understand it (and my understanding is the same as yours), I agree. > > I can work with Eric to incorporate it into > draft-muthu-behave-consent-freshness. However, I would like us to > reach a (rough) consensus on whether the STUN transactions for consent > freshness / liveness should include or omit the message integrity and > thereby use the STUN Binding requests/responses or a new method. > As I've said before, I don't see a value in omitting the message integrity that offsets the (high) cost of introducing a new method. I think we should use the binding request/response. --------------040900020809090203040900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/13/2012 08:34 PM, Muthu Arul Mozhi Perumal (mperumal) wrote:

Taking a closer look at the "Combined Consent/Liveness Proposal II" (slide 16) from Eric's RTCWeb security presentation today, it seems to align closely with what said in WebEx -- determining consent freshness must be under the browser control and determining session liveness must be under the application control. If I understood correctly, the proposal is to have the consent timer Tc under the browser control and the packet receipt timer Tr under the application control. So, I full support it.

To the extent that I understand it (and my understanding is the same as yours), I agree.

 

I can work with Eric to incorporate it into draft-muthu-behave-consent-freshness. However, I would like us to reach a (rough) consensus on whether the STUN transactions for consent freshness / liveness should include or omit the message integrity and thereby use the STUN Binding requests/responses or a new method.

As I've said before, I don't see a value in omitting the message integrity that offsets the (high) cost of introducing a new method. I think we should use the binding request/response.


--------------040900020809090203040900-- From magnus.westerlund@ericsson.com Thu Jun 14 00:15:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766E821F866D for ; Thu, 14 Jun 2012 00:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 mCz+odpa4F2K for ; Thu, 14 Jun 2012 00:15:43 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E8DC021F8671 for ; Thu, 14 Jun 2012 00:15:42 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-9c-4fd98f981a43 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4E.A9.11869.89F89DF4; Thu, 14 Jun 2012 09:15:37 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Thu, 14 Jun 2012 09:15:35 +0200 Message-ID: <4FD98F97.6020506@ericsson.com> Date: Thu, 14 Jun 2012 09:15:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <387F9047F55E8C42850AD6B3A7A03C6C160497E6@inba-mail02.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C160497E6@inba-mail02.sonusnet.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre7M/pv+Bv83s1ncOn2GxWLtv3Z2 ByaPJUt+Mnlc+vyfPYApissmJTUnsyy1SN8ugStj6rsVTAULRCrWbm9nbmBcItDFyMkhIWAi 8fHmNhYIW0ziwr31bCC2kMApRombb1W6GLmA7OWMElOenGQCSfAKaEu8fLWRGcRmEVCVWHjm HSOIzSZgIXHzRyNYs6hAsMSLPVdYIeoFJU7OfAK2QASo5vbSzWA1zALqEncWn2MHsYUFLCVW 9Zxih1jsL9F6pROsnlMgQOL80nesEMdJStxrXw3Vqycx5WoLI4QtL9G8dTYzRK+2RENTB+sE RqFZSFbPQtIyC0nLAkbmVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsYgSF8cMtv1R2Md86JHGKU 5mBREue13rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjq7ra4ox4QTm7dSds92//+Ov/ /8nuMx7a6bauUmsX35z0MtFPLrCo+1pac8SvpAkv+7wElJZyyX3qlju28I/H2v8yvzXfWQZp Cn1bWpsZyXO7/fratb6dPE2PdbjnsBpqlaqbb33Ec26Zxz6PmYauvCIBbwtW5JjEf7qX0eN1 s3bleqv9uUpKLMUZiYZazEXFiQA0oEb2LwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Back-to-back RTP endpoint topology in RTCWeb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 07:15:44 -0000 Hi Partha, I think there is several different realizations of this. If you goal is only to hide one end-points IP address to the other it can be the relay topology, with an 1-1 participation. In fact you don't really need to discuss this as an RTP topology at all as all operations are on IP and Transport level. A TURN server will do perform this hiding in one direction. A web service controlled relay node could do this for both end-points. If your goal is something additional I would claim that this falls in the broad category of things gateways do. The problem is as soon as you enable any RTP/RTCP level of modifications you end up as node needing to be trusted and part of the security contexts. I didn't bring up gateways as they are a bit undefined in their operations as it depends on which aspect they need to change. My general classification of gateways are that they are devices that lets the combination of the peer end-point plus the gateway look like a node expected or at least supported by the communicating party. Cheers Magnus On 2012-06-13 12:46, Ravindran, Parthasarathi wrote: > Hi Magnus & all, > > I like the list of RTP topology mentioned in your interim > presentation. I thought of asking for one more topology namely > Back-to-back RTP endpoint topology in RTCWeb. The topology is as > follows: > > RTP endpoint-----Back-to-back RTP Endpoint-----RTP Endpoint > > The reason for Back-to-back RTP Endpoint topology are > > 1) WebRTC RTP Endpoint to legacy RTP Endpoint (RFC 3550) interop 2) > IP address hiding in WebRTC session > > Even though, Back-to-back RTP Endpoint *MUST* follow RTP Endpoint > behavior, the requirement will be bit more than that as the linkage > with identity, ICE consent, RTCP mandate, set of RTP draft mandates > and other stuffs. Also, the guidelines document for back-to-back RTP > Endpoint shall avoid the blame of intermediate devices always break > the architecture. > > I'm interested in hearing whether Back-to-back RTP endpoint topology > is of interest in RTCWeb. > > Thanks Partha -- 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 andrew.hutton@siemens-enterprise.com Thu Jun 14 02:15:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DE021F8679 for ; Thu, 14 Jun 2012 02:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHE+vluBn4Wg for ; Thu, 14 Jun 2012 02:15:18 -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 518F421F866D for ; Thu, 14 Jun 2012 02:15:14 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 58A8423F05CC; Thu, 14 Jun 2012 11:15:13 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Thu, 14 Jun 2012 11:15:13 +0200 From: "Hutton, Andrew" To: Stefan Hakansson LK , "rtcweb@ietf.org" Thread-Topic: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 Thread-Index: AQHNSWmbwzWI1XkOqEqOJplhksUi75b5fbVw Date: Thu, 14 Jun 2012 09:15:12 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> In-Reply-To: <4FD89773.3090506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.249.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 09:15:18 -0000 On 13 June 2012 15:37 Stefan Hakansson wrote: >=20 > This is my personal understanding: >=20 > - the API (and this part has been there for a long time) allows the > application to disable/enable individual tracks of MediaStreams > - So say you have a MediaStream (one audio track, one video track in > this example) that is rendered using a video element; disabling audio > would lead to silence, disabling video to that the video stops > - The question is: what should happen if the MediaStream is connected > to > a PeerConnection and sent to a peer? > - using recvonly does not seem appropriate as that would stop all > ssrc:s > belonging to the same m-line - and the app only disabled one > - one option could be to simply stop sending the RTP packets for this > track. I don't know how reliable that would be. In the case of outgoing media then I think mute should simply disconnect th= e source (e.g. microphone) and there is no impact on RTP other than dependi= ng on the codec silence will be transmitted or SID frame etc. There is also= no impact on RTCP which continues. This is different to setting the direction to be recvonly which would compl= etely stop the outgoing RTP packets and would normally be signaled to the r= emote party. This should of course be achieved using setLocalDescription. > - I think there has been proposals signaling this in SDP or in RTCP, > but > I don't think there was ever any conclusion If we are talking about a local mute then I don't see any need to signal th= is but again this is different to changing the direction attribute in SDP. >=20 > For the other part, muting incoming media, this is simple: the app (at > receiving browser) could just disable the tracks it wants in the > incoming MediaStreams. A related question is if this should be signaled > back to the sender (so it could stop sending). This is essentially a > question of efficiency/optimization, and nothing stops the app from > signaling that now using an app specific protocol (perhaps carried over > the data channel), but perhaps this should be brought into SDP or RTCP. >=20 If the application wants to ask the remote party to pause sending of RTP th= en it should surely do this in SDP by setting the direction attribute appro= priately (i.e. sendonly or inactive). Regards Andy From harald@alvestrand.no Thu Jun 14 02:19:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05F321F8699 for ; Thu, 14 Jun 2012 02:19:16 -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 Ww36FKaRVaI9 for ; Thu, 14 Jun 2012 02:19:16 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0709921F8679 for ; Thu, 14 Jun 2012 02:19:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F7FE39E091 for ; Thu, 14 Jun 2012 11:19:39 +0200 (CEST) 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 UrcT55+Rd04L for ; Thu, 14 Jun 2012 11:19:38 +0200 (CEST) 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 9497F39E058 for ; Thu, 14 Jun 2012 11:19:38 +0200 (CEST) Message-ID: <4FD9AC8F.7030000@alvestrand.no> Date: Thu, 14 Jun 2012 11:19:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD8A57B.1060708@ericsson.com> In-Reply-To: <4FD8A57B.1060708@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Terminology "Data[gram] stream" (Re: draft-ietf-rtcweb-data-channel-00) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 09:19:16 -0000 On 06/13/2012 04:36 PM, Salvatore Loreto wrote: > On 6/13/12 1:33 PM, DRAGE, Keith (Keith) wrote: >> Quick question. >> >> In this document are "data stream" and "datagram stream" one and the >> same thing, or not? >> >> If yes can we harmonise the term? > thanks > we are going to harmonies the term in the next 01 version Personal preference, weak: Could we harmonize the data channel draft on the term "datagram stream"? It's slightly less likely to be confusing/irritating to people who think that media is data, too.... I'm willing to be convinced the other one is better, but if nobody else has a preference, we might as well do it this way (and I can add the term to the overview document, for document set consistency). > > Salvatore >> >> If no, can we define what the distinct terms mean? >> >> Keith >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu Jun 14 02:21:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E68621F8555 for ; Thu, 14 Jun 2012 02:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=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 2-UuqBCsA3+8 for ; Thu, 14 Jun 2012 02:21:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E6F0A21F846A for ; Thu, 14 Jun 2012 02:21:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 133EB39E091 for ; Thu, 14 Jun 2012 11:22:02 +0200 (CEST) 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 rXPhFafDevt5 for ; Thu, 14 Jun 2012 11:22:01 +0200 (CEST) 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 D226E39E058 for ; Thu, 14 Jun 2012 11:22:00 +0200 (CEST) Message-ID: <4FD9AD1E.6060504@alvestrand.no> Date: Thu, 14 Jun 2012 11:21:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 09:21:38 -0000 Changing the subject line again, since we're discussing how to do mute, not whether to do it..... On 06/14/2012 11:15 AM, Hutton, Andrew wrote: > On 13 June 2012 15:37 Stefan Hakansson wrote: > >> This is my personal understanding: >> >> - the API (and this part has been there for a long time) allows the >> application to disable/enable individual tracks of MediaStreams >> - So say you have a MediaStream (one audio track, one video track in >> this example) that is rendered using a video element; disabling audio >> would lead to silence, disabling video to that the video stops >> - The question is: what should happen if the MediaStream is connected >> to >> a PeerConnection and sent to a peer? >> - using recvonly does not seem appropriate as that would stop all >> ssrc:s >> belonging to the same m-line - and the app only disabled one >> - one option could be to simply stop sending the RTP packets for this >> track. I don't know how reliable that would be. > In the case of outgoing media then I think mute should simply disconnect the source (e.g. microphone) and there is no impact on RTP other than depending on the codec silence will be transmitted or SID frame etc. There is also no impact on RTCP which continues. > > This is different to setting the direction to be recvonly which would completely stop the outgoing RTP packets and would normally be signaled to the remote party. This should of course be achieved using setLocalDescription. Just to add to the complexity of the "mute" case: When an audio stream is muted, should there be comfort noise sent? If yes, what should determine the noise level? (people who've never had to deal with comfort noise can safely tune out at this point) > > >> - I think there has been proposals signaling this in SDP or in RTCP, >> but >> I don't think there was ever any conclusion > If we are talking about a local mute then I don't see any need to signal this but again this is different to changing the direction attribute in SDP. > >> For the other part, muting incoming media, this is simple: the app (at >> receiving browser) could just disable the tracks it wants in the >> incoming MediaStreams. A related question is if this should be signaled >> back to the sender (so it could stop sending). This is essentially a >> question of efficiency/optimization, and nothing stops the app from >> signaling that now using an app specific protocol (perhaps carried over >> the data channel), but perhaps this should be brought into SDP or RTCP. >> > If the application wants to ask the remote party to pause sending of RTP then it should surely do this in SDP by setting the direction attribute appropriately (i.e. sendonly or inactive). > > Regards > Andy > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From salvatore.loreto@ericsson.com Thu Jun 14 02:22:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD6E21F8699 for ; Thu, 14 Jun 2012 02:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 025Zpc5D7ZZb for ; Thu, 14 Jun 2012 02:22:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6F21F85D1 for ; Thu, 14 Jun 2012 02:22:39 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-a6-4fd9ad5e06ca Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 64.43.00702.E5DA9DF4; Thu, 14 Jun 2012 11:22:38 +0200 (CEST) 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.264.0; Thu, 14 Jun 2012 11:22:38 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2EED822EE for ; Thu, 14 Jun 2012 12:22:38 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 388FE531A9 for ; Thu, 14 Jun 2012 12:22:38 +0300 (EEST) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DEB8453191 for ; Thu, 14 Jun 2012 12:22:37 +0300 (EEST) Message-ID: <4FD9AD5D.2000408@ericsson.com> Date: Thu, 14 Jun 2012 12:22:37 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4FD8A57B.1060708@ericsson.com> <4FD9AC8F.7030000@alvestrand.no> In-Reply-To: <4FD9AC8F.7030000@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+JvrW7c2pv+Bifa9S3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrLl31kKZnFXnDl2maWBsZ+zi5GTQ0LAROLZ4aksELaYxIV7 69m6GLk4hAROMUp8fLyHGSQhJLCBUWLSjgCIxEVGiQWLl7BCOEcYJVas+gfl7GWUaO+9wdjF yMHBK6AtcXSaAIjJIqAq8XeeEMggNgEziecPt4ANFRVIlug93wBm8woISpyc+QTsChEBYYmt r3qZQGxhgViJA/NbmSDGz2OUmNr6lg0kwSmgK3Hr0C8wm1nAVuLCnOssELa8xPa3c5gh3lGT uHpuE9QHWhK9ZzuZJjCKzEKybxaS9llI2hcwMq9iFM5NzMxJLzfXSy3KTC4uzs/TK07dxAgM 8YNbfhvsYNx0X+wQozQHi5I4r57qfn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjMwur3WO N+5V1WfMsIw8uf9kw77oM16TuXtsJvJkBi8r2PdQMFzqWvtD8z+ziudW8M0t3PVA03DJWWuu JJVd3/IfPH66eInXZJESOdenFyPyI8oab71Omfadraopi/Op98v+xHffdW/Pf/ChvKdw6UW+ s7GmDw4vc3R4eoPb3e5F8yK736sOn1diKc5INNRiLipOBAClIDtMPwIAAA== Subject: Re: [rtcweb] Terminology "Data[gram] stream" (Re: draft-ietf-rtcweb-data-channel-00) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 09:22:42 -0000 On 6/14/12 12:19 PM, Harald Alvestrand wrote: > On 06/13/2012 04:36 PM, Salvatore Loreto wrote: >> On 6/13/12 1:33 PM, DRAGE, Keith (Keith) wrote: >>> Quick question. >>> >>> In this document are "data stream" and "datagram stream" one and the >>> same thing, or not? >>> >>> If yes can we harmonise the term? >> thanks >> we are going to harmonies the term in the next 01 version > Personal preference, weak: > > Could we harmonize the data channel draft on the term "datagram stream"? > It's slightly less likely to be confusing/irritating to people who think > that media is data, too.... that is exactly what I have in mind to do! > > I'm willing to be convinced the other one is better, but if nobody else > has a preference, we might as well do it this way (and I can add the > term to the overview document, for document set consistency). that would be great! > > >> Salvatore >>> If no, can we define what the distinct terms mean? >>> >>> Keith >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Thu Jun 14 06:10:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A663221F865E for ; Thu, 14 Jun 2012 06:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_41=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 PR3+eT+dpxHa for ; Thu, 14 Jun 2012 06:10:25 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9236B21F86B7 for ; Thu, 14 Jun 2012 06:10:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-50-4fd9e2bff60b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3C.05.28636.FB2E9DF4; Thu, 14 Jun 2012 15:10:23 +0200 (CEST) Received: from [150.132.142.244] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Thu, 14 Jun 2012 15:10:23 +0200 Message-ID: <4FD9E2BE.2080907@ericsson.com> Date: Thu, 14 Jun 2012 15:10:22 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> In-Reply-To: <4FD9AD1E.6060504@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvre7+Rzf9Df72KFus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ/PLjIW/JKu2NB7g6WB8aBYFyMnh4SAicTanctZIGwxiQv3 1rN1MXJxCAmcYpTo+tbMAuGsZZQ49PY0E0gVr4C2xNfrG9lAbBYBVYmtyx6yg9hsAjYSa7un ANVwcIgKhEmsfqABUS4ocXLmE7AFIgLCEltf9YKNERYolLg/6SArxPxzLBJz5mwBm8MpoCux 8nUT2HxmAVuJC3Ous0DY8hLb385hBrGFgGrevb7HOoFRYBaSHbOQtMxC0rKAkXkVo3BuYmZO ermhXmpRZnJxcX6eXnHqJkZgAB7c8lt3B+OpcyKHGKU5WJTEebmS9vsLCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYEx+YP6pV5JhzWXd8oyPVjtzd6jwq/+03vyyyLWI+fXsOT7TOKQnHm7+ yHvyDg/bmpqm0vIattNbbr2fwMdkKyTfzqXJLmGbrZCvJWs569OVfw5zP3/zvZk4R09batmr uv+ZG/gP/wg4dKN2zZGn543aVjCcOfDbhGvdHyGz/p319TrzzJtTjyqxFGckGmoxFxUnAgB7 UE4bDgIAAA== Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 13:10:25 -0000 On 06/14/2012 11:21 AM, Harald Alvestrand wrote: > Changing the subject line again, since we're discussing how to do > mute, not whether to do it..... > > On 06/14/2012 11:15 AM, Hutton, Andrew wrote: >> On 13 June 2012 15:37 Stefan Hakansson wrote: >> >>> This is my personal understanding: >>> >>> - the API (and this part has been there for a long time) allows >>> the application to disable/enable individual tracks of >>> MediaStreams - So say you have a MediaStream (one audio track, >>> one video track in this example) that is rendered using a video >>> element; disabling audio would lead to silence, disabling video >>> to that the video stops - The question is: what should happen if >>> the MediaStream is connected to a PeerConnection and sent to a >>> peer? - using recvonly does not seem appropriate as that would >>> stop all ssrc:s belonging to the same m-line - and the app only >>> disabled one - one option could be to simply stop sending the RTP >>> packets for this track. I don't know how reliable that would be. >> In the case of outgoing media then I think mute should simply >> disconnect the source (e.g. microphone) and there is no impact on >> RTP other than depending on the codec silence will be transmitted >> or SID frame etc. There is also no impact on RTCP which continues. >> >> This is different to setting the direction to be recvonly which >> would completely stop the outgoing RTP packets and would normally >> be signaled to the remote party. This should of course be achieved >> using setLocalDescription. > > Just to add to the complexity of the "mute" case: > > When an audio stream is muted, should there be comfort noise sent? If > yes, what should determine the noise level? To me it feels as that ideally we should stop sending RTP (and make the other end know that the track is disabled). If we go to comfort noise state, the track in the MediaStream at the other end would still be active (even though what is played could be very low level comfort noise), but to reflect the local state the remote track should go to "muted", shouldn't it? > > (people who've never had to deal with comfort noise can safely tune > out at this point) > >> >> >>> - I think there has been proposals signaling this in SDP or in >>> RTCP, but I don't think there was ever any conclusion >> If we are talking about a local mute then I don't see any need to >> signal this but again this is different to changing the direction >> attribute in SDP. >> >>> For the other part, muting incoming media, this is simple: the >>> app (at receiving browser) could just disable the tracks it wants >>> in the incoming MediaStreams. A related question is if this >>> should be signaled back to the sender (so it could stop sending). >>> This is essentially a question of efficiency/optimization, and >>> nothing stops the app from signaling that now using an app >>> specific protocol (perhaps carried over the data channel), but >>> perhaps this should be brought into SDP or RTCP. >>> >> If the application wants to ask the remote party to pause sending >> of RTP then it should surely do this in SDP by setting the >> direction attribute appropriately (i.e. sendonly or inactive). >> >> Regards Andy >> >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu Jun 14 09:08:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B540E21F86E4 for ; Thu, 14 Jun 2012 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.332 X-Spam-Level: X-Spam-Status: No, score=-4.332 tagged_above=-999 required=5 tests=[AWL=-0.733, 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 FiTxmtkvv-e5 for ; Thu, 14 Jun 2012 09:08:20 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04DA221F86CE for ; Thu, 14 Jun 2012 09:08:19 -0700 (PDT) Received: by bkty8 with SMTP id y8so1829564bkt.31 for ; Thu, 14 Jun 2012 09:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d7V1ZIyCSF/FwggHQ9FtKZYqYTxJDLgGxjAXTEPfrps=; b=Y/o+SdkQCpCFJDrCi7rFhhSOBIadE2qxViHFnihdY42Vug6p2suSKQfAKFgeSTJuvp 1LiyVnvgYFglCbf9c0wDZhi//ynu+jhhVZIYHy7BP1KDzWlNrJGngqlbqbGYGy60Q9w+ YPD/Qqvc4ZSmujopXatV6fTLfAGl7qt5NLOLelbIs98H1gfd6swQlBkTMEBMi6KBN8q3 +ZDNjRVVuRtwYv6i8c2yYRnqEh8f8j525w0IKpwEsLwioXp0qTNW8nFN0Fp9dE/PnxN1 meaw3DGFZ/1esuiaZXZaxgATE+sRV7xmQOcMBsALiAPy4u5I3PiEI+n2uBMSnzI03pWK hyMg== MIME-Version: 1.0 Received: by 10.204.150.84 with SMTP id x20mr1435899bkv.26.1339690098855; Thu, 14 Jun 2012 09:08:18 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Thu, 14 Jun 2012 09:08:18 -0700 (PDT) In-Reply-To: <4FD984D5.80207@alvestrand.no> References: <4FD984D5.80207@alvestrand.no> Date: Thu, 14 Jun 2012 09:08:18 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Combining consent freshness and liveness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 16:08:20 -0000 On 13 June 2012 23:29, Harald Alvestrand wrote: > As I've said before, I don't see a value in omitting the message integrity > that offsets the (high) cost of introducing a new method. I think we should > use the binding request/response. While it was acknowledged that the security analysis didn't depend on having the integrity check, I completely agree with Harald. ...for at least these reasons: * As discussed, the additional cost of introducing a method, which I cannot emphasize enough is quite high. * Reusing the binding request allows browsers to interoperate with existing ICE agents; even ICE-lite agents. That's really important. I'm sympathetic to the cost of calculating SHA-1, but is not so expensive (either in terms of packets or in terms of CPU cycles) that it warrants breaking these. From bernard_aboba@hotmail.com Thu Jun 14 11:58:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EB021F872D for ; Thu, 14 Jun 2012 11:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLc5O+U6q6VH for ; Thu, 14 Jun 2012 11:58:43 -0700 (PDT) Received: from blu0-omc4-s24.blu0.hotmail.com (blu0-omc4-s24.blu0.hotmail.com [65.55.111.163]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5621F8716 for ; Thu, 14 Jun 2012 11:58:42 -0700 (PDT) Received: from BLU169-W101 ([65.55.111.136]) by blu0-omc4-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jun 2012 11:58:42 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9c73674c-6316-4b3e-b95d-97a7c04051fd_" X-Originating-IP: [131.107.0.115] From: Bernard Aboba To: , Date: Thu, 14 Jun 2012 11:58:41 -0700 Importance: Normal In-Reply-To: References: , <4FD984D5.80207@alvestrand.no>, MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jun 2012 18:58:42.0570 (UTC) FILETIME=[B79116A0:01CD4A5F] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Combining consent freshness and liveness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 18:58:43 -0000 --_9c73674c-6316-4b3e-b95d-97a7c04051fd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree that introducing a new method is not a good idea. ICE has been imple= mented and deployed=2C and so we should not be breaking interoperability without a= very good reason. =20 The cost of SHA-1 computation is not a good enough justification for the pa= in a=20 new method would cause.=20 > Date: Thu=2C 14 Jun 2012 09:08:18 -0700 > From: martin.thomson@gmail.com > To: harald@alvestrand.no > CC: rtcweb@ietf.org > Subject: Re: [rtcweb] Combining consent freshness and liveness >=20 > On 13 June 2012 23:29=2C Harald Alvestrand wrote: > > As I've said before=2C I don't see a value in omitting the message inte= grity > > that offsets the (high) cost of introducing a new method. I think we sh= ould > > use the binding request/response. >=20 > While it was acknowledged that the security analysis didn't depend on > having the integrity check=2C I completely agree with Harald. ...for at > least these reasons: > * As discussed=2C the additional cost of introducing a method=2C which I > cannot emphasize enough is quite high. > * Reusing the binding request allows browsers to interoperate with > existing ICE agents=3B even ICE-lite agents. That's really important. >=20 > I'm sympathetic to the cost of calculating SHA-1=2C but is not so > expensive (either in terms of packets or in terms of CPU cycles) that > it warrants breaking these. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_9c73674c-6316-4b3e-b95d-97a7c04051fd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Agree that introducing a new method is not a good idea. =3B ICE has bee= n implemented
and deployed=2C and so we should not be breaking interoper= ability without a very good
reason. =3B

The cost of SHA-1 co= mputation is not a good enough justification for the pain a
new method = would cause.

>=3B Date= : Thu=2C 14 Jun 2012 09:08:18 -0700
>=3B From: martin.thomson@gmail.co= m
>=3B To: harald@alvestrand.no
>=3B CC: rtcweb@ietf.org
>= =3B Subject: Re: [rtcweb] Combining consent freshness and liveness
>= =3B
>=3B On 13 June 2012 23:29=2C Harald Alvestrand <=3Bharald@alve= strand.no>=3B wrote:
>=3B >=3B As I've said before=2C I don't see = a value in omitting the message integrity
>=3B >=3B that offsets the= (high) cost of introducing a new method. I think we should
>=3B >= =3B use the binding request/response.
>=3B
>=3B While it was ack= nowledged that the security analysis didn't depend on
>=3B having the = integrity check=2C I completely agree with Harald. ...for at
>=3B lea= st these reasons:
>=3B * As discussed=2C the additional cost of intro= ducing a method=2C which I
>=3B cannot emphasize enough is quite high.=
>=3B * Reusing the binding request allows browsers to interoperate w= ith
>=3B existing ICE agents=3B even ICE-lite agents. That's really i= mportant.
>=3B
>=3B I'm sympathetic to the cost of calculating S= HA-1=2C but is not so
>=3B expensive (either in terms of packets or in= terms of CPU cycles) that
>=3B it warrants breaking these.
>=3B = _______________________________________________
>=3B rtcweb mailing li= st
>=3B rtcweb@ietf.org
>=3B https://www.ietf.org/mailman/listinf= o/rtcweb
= --_9c73674c-6316-4b3e-b95d-97a7c04051fd_-- From juberti@google.com Thu Jun 14 12:37:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA3B21F864A for ; Thu, 14 Jun 2012 12:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.843 X-Spam-Level: X-Spam-Status: No, score=-101.843 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8sRfZJPMnfA for ; Thu, 14 Jun 2012 12:37:17 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A183F21F861D for ; Thu, 14 Jun 2012 12:37:16 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1890544ghb.31 for ; Thu, 14 Jun 2012 12:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=phuhA06uQRwnLuFgjUYHecYldoGfV27WHJkzTHhjLJ8=; b=byxeFZGXMmpejamreHdL+0vxfTkfk/9XIg0L13VJRI3WA7cermROMkwMw2yD5sZ/gf +TE6QfZCNJmLbLiYV5YWGk6yPmp2NxRWn6b8H5Ab4i8y4LrpbgiseI3tosdNO0+ntj6d HycEwo5NRy9uOJK9Xh7QgwY6FvzCBNBoMoRsu/85Ucw9Bnmf6QoPFKiL9AEwa2nLDdDk GPAFKY8A7lyZo5ziqeUp3FSmtUNSAbugLKxuvWnVp/X+HFvzG/S2jxxhrb9H1zBwhFhH 9PIhm1xZJzVBpGhROT1qDdmFwNonBvK2BM7Yog+ZGhqByGOTirlyUBhA97/zQsKDy6u9 S/LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=phuhA06uQRwnLuFgjUYHecYldoGfV27WHJkzTHhjLJ8=; b=GuJJcHM+XPGYVyq9Qrw6NlOIvnE84jTOA0cjDPFvBHltnNusdQJubyriNUtzXsPfC5 Us7kPU3meGdNAAU8AZkP8d8b9xrKM1uw+F9MlvcT8DtLKktITShYgDoCzk8Hc5ZI+hgG MsjPUzjZF43tVX1+DnZMIFtviv63o3kx7y7Dt1boYhbdXLBG+HRnIb6bCcBmK7eL2SEq Jzb5DW1mCyZDCLZZ3dWGq7hqTw3poMpFbf0WG7qmZF6gh76+059qdHpt91SZpbH9KRGk UbZULVd+iLdrqaKpXKVVI7iaC29uFDcYBRhOoQzkib9BW+GZW7YFJENBJOv4c/52VvNV jYPw== Received: by 10.50.183.228 with SMTP id ep4mr13584705igc.74.1339702635692; Thu, 14 Jun 2012 12:37:15 -0700 (PDT) Received: by 10.50.183.228 with SMTP id ep4mr13584699igc.74.1339702635564; Thu, 14 Jun 2012 12:37:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.218 with HTTP; Thu, 14 Jun 2012 12:36:55 -0700 (PDT) In-Reply-To: <4FD9E2BE.2080907@ericsson.com> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com> From: Justin Uberti Date: Thu, 14 Jun 2012 15:36:55 -0400 Message-ID: To: Stefan Hakansson LK Content-Type: multipart/alternative; boundary=14dae934064fb2900404c273d3e2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnm0cO6gWSmB3/bFOc+nAuFoL4p09ztYnY2HNSew5GLdIQ1J0UQsSPiuSN+mooC/frW0rcauuarV0WW2FPfITY602PbFVqe6wMksXUfuIvTFDXngqKYr+dc7ClAzA+3DxxryuIE Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 19:37:18 -0000 --14dae934064fb2900404c273d3e2 Content-Type: text/plain; charset=UTF-8 For "mute", stopping sending of RTP may trigger concealment on the remote side. We currently send silent audio when muted to prevent this. For "hold", you are notifying the remote side (e.g. a=inactive), so it makes sense to stop sending RTP. On Thu, Jun 14, 2012 at 9:10 AM, Stefan Hakansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 06/14/2012 11:21 AM, Harald Alvestrand wrote: > >> Changing the subject line again, since we're discussing how to do >> mute, not whether to do it..... >> >> On 06/14/2012 11:15 AM, Hutton, Andrew wrote: >> >>> On 13 June 2012 15:37 Stefan Hakansson wrote: >>> >>> This is my personal understanding: >>>> >>>> - the API (and this part has been there for a long time) allows >>>> the application to disable/enable individual tracks of >>>> MediaStreams - So say you have a MediaStream (one audio track, >>>> one video track in this example) that is rendered using a video >>>> element; disabling audio would lead to silence, disabling video >>>> to that the video stops - The question is: what should happen if >>>> the MediaStream is connected to a PeerConnection and sent to a >>>> peer? - using recvonly does not seem appropriate as that would >>>> stop all ssrc:s belonging to the same m-line - and the app only >>>> disabled one - one option could be to simply stop sending the RTP >>>> packets for this track. I don't know how reliable that would be. >>>> >>> In the case of outgoing media then I think mute should simply >>> disconnect the source (e.g. microphone) and there is no impact on >>> RTP other than depending on the codec silence will be transmitted >>> or SID frame etc. There is also no impact on RTCP which continues. >>> >>> This is different to setting the direction to be recvonly which >>> would completely stop the outgoing RTP packets and would normally >>> be signaled to the remote party. This should of course be achieved >>> using setLocalDescription. >>> >> >> Just to add to the complexity of the "mute" case: >> >> When an audio stream is muted, should there be comfort noise sent? If >> yes, what should determine the noise level? >> > > To me it feels as that ideally we should stop sending RTP (and make the > other end know that the track is disabled). If we go to comfort noise > state, the track in the MediaStream at the other end would still be active > (even though what is played could be very low level comfort noise), but to > reflect the local state the remote track should go to "muted", shouldn't it? > > > > >> (people who've never had to deal with comfort noise can safely tune >> out at this point) >> >> >>> >>> - I think there has been proposals signaling this in SDP or in >>>> RTCP, but I don't think there was ever any conclusion >>>> >>> If we are talking about a local mute then I don't see any need to >>> signal this but again this is different to changing the direction >>> attribute in SDP. >>> >>> For the other part, muting incoming media, this is simple: the >>>> app (at receiving browser) could just disable the tracks it wants >>>> in the incoming MediaStreams. A related question is if this >>>> should be signaled back to the sender (so it could stop sending). >>>> This is essentially a question of efficiency/optimization, and >>>> nothing stops the app from signaling that now using an app >>>> specific protocol (perhaps carried over the data channel), but >>>> perhaps this should be brought into SDP or RTCP. >>>> >>>> If the application wants to ask the remote party to pause sending >>> of RTP then it should surely do this in SDP by setting the >>> direction attribute appropriately (i.e. sendonly or inactive). >>> >>> Regards Andy >>> >>> ______________________________**_________________ rtcweb mailing >>> list rtcweb@ietf.org https://www.ietf.org/mailman/**listinfo/rtcweb >>> >> >> ______________________________**_________________ rtcweb mailing list >> rtcweb@ietf.org https://www.ietf.org/mailman/**listinfo/rtcweb >> > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --14dae934064fb2900404c273d3e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For "mute&= quot;, stopping sending of RTP may trigger concealment on the remote side. = We currently send silent audio when muted to prevent this.
For "hold", you are notifying the remote side (e.g. a=3Dinactive)= , so it makes sense to stop sending RTP.

= On Thu, Jun 14, 2012 at 9:10 AM, Stefan Hakansson LK <= stefa= n.lk.hakansson@ericsson.com> wrote:
On 0= 6/14/2012 11:21 AM, Harald Alvestrand wrote:
Changing the subject line again, since we're discussing how to do
mute, not whether to do it.....

On 06/14/2012 11:15 AM, Hutton, Andrew wrote:
On 13 June 2012 15:37 Stefan Hakansson wrote:

This is my personal understanding:

- the API (and this part has been there for a long time) allows
the application to disable/enable individual tracks of
MediaStreams - So say you have a MediaStream (one audio track,
one video track in this example) that is rendered using a video
element; disabling audio would lead to silence, disabling video
to that the video stops - The question is: what should happen if
the MediaStream is connected to a PeerConnection and sent to a
peer? - using recvonly does not seem appropriate as that would
stop all ssrc:s belonging to the same m-line - and the app only
disabled one - one option could be to simply stop sending the RTP
packets for this track. I don't know how reliable that would be.
In the case of outgoing media then I think mute should simply
disconnect the source (e.g. microphone) and there is no impact on
RTP other than depending on the codec silence will be transmitted
or SID frame etc. There is also no impact on RTCP which continues.

This is different to setting the direction to be recvonly which
would completely stop the outgoing RTP packets and would normally
be signaled to the remote party. This should of course be achieved
using setLocalDescription.

Just to add to the complexity of the "mute" case:

When an audio stream is muted, should there be comfort noise sent? If
yes, what should determine the noise level?

To me it feels as that ideally we should stop sending RTP (and make the oth= er end know that the track is disabled). If we go to comfort noise state, t= he track in the MediaStream at the other end would still be active (even th= ough what is played could be very low level comfort noise), but to reflect = the local state the remote track should go to "muted", shouldn= 9;t it?




(people who've never had to deal with comfort noise can safely tune
out at this point)



- I think there has been proposals signaling this in SDP or in
RTCP, but I don't think there was ever any conclusion
If we are talking about a local mute then I don't see any need to
signal this but again this is different to changing the direction
attribute in SDP.

For the other part, muting incoming media, this is simple: the
app (at receiving browser) could just disable the tracks it wants
in the incoming MediaStreams. A related question is if this
should be signaled back to the sender (so it could stop sending).
This is essentially a question of efficiency/optimization, and
nothing stops the app from signaling that now using an app
specific protocol (perhaps carried over the data channel), but
perhaps this should be brought into SDP or RTCP.

If the application wants to ask the remote party to pause sending
of RTP then it should surely do this in SDP by setting the
direction attribute appropriately (i.e. sendonly or inactive).

Regards Andy

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

_______________________________________________ rtcweb mailing list<= br> rtcweb@ietf.org ht= tps://www.ietf.org/mailman/listinfo/rtcweb

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

--14dae934064fb2900404c273d3e2-- From andrew.hutton@siemens-enterprise.com Thu Jun 14 13:01:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5031121F86D4 for ; Thu, 14 Jun 2012 13:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyxuVQYLQY9X for ; Thu, 14 Jun 2012 13:01:13 -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 A6D4E21F86BD for ; Thu, 14 Jun 2012 13:01:12 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 93E1223F05E9; Thu, 14 Jun 2012 22:01:11 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Thu, 14 Jun 2012 22:01:11 +0200 From: "Hutton, Andrew" To: Justin Uberti Thread-Topic: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) Thread-Index: AQHNSi8V99bC4xTMh0uQV/Y6A7X7Fpb6FDaAgAAoTow= Date: Thu, 14 Jun 2012 20:01:10 +0000 Message-ID: <8A7A43A8-90B0-46E0-83C4-E950BC4A3B2C@siemens-enterprise.com> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8A7A43A890B046E083C4E950BC4A3B2Csiemensenterprisecom_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:01:14 -0000 --_000_8A7A43A890B046E083C4E950BC4A3B2Csiemensenterprisecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Justin that mute is a local action and should not stop the RTP= or change the state of the remote track. Regards Andy On 14 Jun 2012, at 20:37, "Justin Uberti" > wrote: For "mute", stopping sending of RTP may trigger concealment on the remote s= ide. We currently send silent audio when muted to prevent this. For "hold", you are notifying the remote side (e.g. a=3Dinactive), so it ma= kes sense to stop sending RTP. On Thu, Jun 14, 2012 at 9:10 AM, Stefan Hakansson LK > wrote: On 06/14/2012 11:21 AM, Harald Alvestrand wrote: Changing the subject line again, since we're discussing how to do mute, not whether to do it..... On 06/14/2012 11:15 AM, Hutton, Andrew wrote: On 13 June 2012 15:37 Stefan Hakansson wrote: This is my personal understanding: - the API (and this part has been there for a long time) allows the application to disable/enable individual tracks of MediaStreams - So say you have a MediaStream (one audio track, one video track in this example) that is rendered using a video element; disabling audio would lead to silence, disabling video to that the video stops - The question is: what should happen if the MediaStream is connected to a PeerConnection and sent to a peer? - using recvonly does not seem appropriate as that would stop all ssrc:s belonging to the same m-line - and the app only disabled one - one option could be to simply stop sending the RTP packets for this track. I don't know how reliable that would be. In the case of outgoing media then I think mute should simply disconnect the source (e.g. microphone) and there is no impact on RTP other than depending on the codec silence will be transmitted or SID frame etc. There is also no impact on RTCP which continues. This is different to setting the direction to be recvonly which would completely stop the outgoing RTP packets and would normally be signaled to the remote party. This should of course be achieved using setLocalDescription. Just to add to the complexity of the "mute" case: When an audio stream is muted, should there be comfort noise sent? If yes, what should determine the noise level? To me it feels as that ideally we should stop sending RTP (and make the oth= er end know that the track is disabled). If we go to comfort noise state, t= he track in the MediaStream at the other end would still be active (even th= ough what is played could be very low level comfort noise), but to reflect = the local state the remote track should go to "muted", shouldn't it? (people who've never had to deal with comfort noise can safely tune out at this point) - I think there has been proposals signaling this in SDP or in RTCP, but I don't think there was ever any conclusion If we are talking about a local mute then I don't see any need to signal this but again this is different to changing the direction attribute in SDP. For the other part, muting incoming media, this is simple: the app (at receiving browser) could just disable the tracks it wants in the incoming MediaStreams. A related question is if this should be signaled back to the sender (so it could stop sending). This is essentially a question of efficiency/optimization, and nothing stops the app from signaling that now using an app specific protocol (perhaps carried over the data channel), but perhaps this should be brought into SDP or RTCP. If the application wants to ask the remote party to pause sending of RTP then it should surely do this in SDP by setting the direction attribute appropriately (i.e. sendonly or inactive). Regards Andy _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/l= istinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listin= fo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_8A7A43A890B046E083C4E950BC4A3B2Csiemensenterprisecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with Justin that mute is a local action and should not stop th= e RTP or change the state of the remote track.

Regards
Andy



On 14 Jun 2012, at 20:37, "Justin Uberti" <juberti@google.com> wrote:

For "mute&= quot;, stopping sending of RTP may trigger concealment on the remote side. = We currently send silent audio when muted to prevent this.
For "hold", you are notifying the remote side (e.g. a=3Dinac= tive), so it makes sense to stop sending RTP.

On Thu, Jun 14, 2012 at 9:10 AM, Stefan Hakansso= n LK <s= tefan.lk.hakansson@ericsson.com> wrote:
On 06/14/2012 11:21 AM, Harald Alvestrand wrote:
Changing the subject line again, since we're discussing how to do
mute, not whether to do it.....

On 06/14/2012 11:15 AM, Hutton, Andrew wrote:
On 13 June 2012 15:37 Stefan Hakansson wrote:

This is my personal understanding:

- the API (and this part has been there for a long time) allows
the application to disable/enable individual tracks of
MediaStreams - So say you have a MediaStream (one audio track,
one video track in this example) that is rendered using a video
element; disabling audio would lead to silence, disabling video
to that the video stops - The question is: what should happen if
the MediaStream is connected to a PeerConnection and sent to a
peer? - using recvonly does not seem appropriate as that would
stop all ssrc:s belonging to the same m-line - and the app only
disabled one - one option could be to simply stop sending the RTP
packets for this track. I don't know how reliable that would be.
In the case of outgoing media then I think mute should simply
disconnect the source (e.g. microphone) and there is no impact on
RTP other than depending on the codec silence will be transmitted
or SID frame etc. There is also no impact on RTCP which continues.

This is different to setting the direction to be recvonly which
would completely stop the outgoing RTP packets and would normally
be signaled to the remote party. This should of course be achieved
using setLocalDescription.

Just to add to the complexity of the "mute" case:

When an audio stream is muted, should there be comfort noise sent? If
yes, what should determine the noise level?

To me it feels as that ideally we should stop sending RTP (and make the oth= er end know that the track is disabled). If we go to comfort noise state, t= he track in the MediaStream at the other end would still be active (even th= ough what is played could be very low level comfort noise), but to reflect the local state the remote track = should go to "muted", shouldn't it?




(people who've never had to deal with comfort noise can safely tune
out at this point)



- I think there has been proposals signaling this in SDP or in
RTCP, but I don't think there was ever any conclusion
If we are talking about a local mute then I don't see any need to
signal this but again this is different to changing the direction
attribute in SDP.

For the other part, muting incoming media, this is simple: the
app (at receiving browser) could just disable the tracks it wants
in the incoming MediaStreams. A related question is if this
should be signaled back to the sender (so it could stop sending).
This is essentially a question of efficiency/optimization, and
nothing stops the app from signaling that now using an app
specific protocol (perhaps carried over the data channel), but
perhaps this should be brought into SDP or RTCP.

If the application wants to ask the remote party to pause sending
of RTP then it should surely do this in SDP by setting the
direction attribute appropriately (i.e. sendonly or inactive).

Regards Andy

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

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

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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_8A7A43A890B046E083C4E950BC4A3B2Csiemensenterprisecom_-- From jonathan@vidyo.com Thu Jun 14 13:03:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E451421F876E for ; Thu, 14 Jun 2012 13:03: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 oQ4tjWtv5fuo for ; Thu, 14 Jun 2012 13:03:20 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 64CBC21F876D for ; Thu, 14 Jun 2012 13:03:20 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 777E98BE6DC for ; Thu, 14 Jun 2012 16:03:19 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id EC7DD8BEA7A for ; Thu, 14 Jun 2012 16:03:18 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Thu, 14 Jun 2012 16:02:50 -0400 From: Jonathan Lennox To: "rtcweb@ietf.org" Date: Thu, 14 Jun 2012 16:03:17 -0400 Thread-Topic: [rtcweb] What I think we need to do about ICE Thread-Index: Ac1KaK5tvXVb1HIcTte9CSUNz/wtcQ== Message-ID: <73851E92-3D9D-43FE-8F51-C893D8D755AA@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] What I think we need to do about ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:03:22 -0000 On Jun 12, 2012, at 10:32 AM, Eric Rescorla wrote: > To recap what I was saying on the list: >=20 > 1. Some method of determining when a candidate pair has failed. >=20 > 2. Some method of failing over to another candidate pair after > failure in as clean a fashion as possible, preferably exploiting > the fact that we already know about other valid candidate pairs, > if possible. Example: I had a direct and relayed pair that worked > and I chose direct. Is there a way to fall back to relayed without > doing a total re-ice. >=20 > 3. When I discover a new candidate pair, some way of investigating > it and maybe changing to it w/o interfering with my current active > candidate pair. >=20 > I think we need to do (1) and probably (2) now and (3) is a nice to have. >From the point of view of RFC 5245, during an ICE Restart "media can contin= ue to be sent to the previously validated pair." (9.1.1.1 and 11.1.1). So = 3) should come for free, if implementations are written properly. Here's the model of ICE as I understand it. An endpoint is always free to = gather as many or as few candidates as it wants, at any time before it star= ts ICE or an ICE Restart. This includes the currently-selected candidate, = and any other previously-validated candidates that happen to still be live. Thus, an ICE Restart doesn't have to be a "total re-ice", necessarily. If = you send (e.g.) your current selected candidate, and one other newly-discov= ered candidate, as your candidate set for an ICE restart, the restart's con= nectivity checking should be lighter-weight than one where you give the lis= t of every possible candidate (which you presumably would do for the sessio= n's initial ICE exchange). But it's still a full and compliant ICE connect= ivity check. That said, ICE says that once you're in "ICE Completed" state, the only way= to change a component's selected candidate pair is by doing an ICE restart= . Trickle candidates are equivalent to candidates sent in an updated offer or= answer in the "ICE Running" state (9.1.2.1 / 9.2.2.1). Thus, they're igno= red once an endpoint enters "ICE Completed" state. ICE leaves a lot of endpoint behavior up to endpoint implementors, and in t= he webrtc context I think many of these behaviors will need to be controlla= ble by the javascript applications. I think the following APIs may be need= ed. (Some of them may exist already in the w3 draft, I haven't followed al= l its details). * Some way to know when something interesting has happened to network conne= ctivity, above and beyond EKR's 1). This includes a new network interface = coming up, or even potentially (if possible) a something more interesting l= ike a captive portal becoming unblocked. * Some way to configure the set of interfaces on which address gathering sh= ould be done, and the priority among them. (This implies there also needs = to be way to interrogate the set of interfaces.) * Some way to start address gathering, both for the initial PeerConnection = setup and for an ICE restart. Note that this needs to be done both by the = offerer and the answerer, and in many cases an answerer won't know it needs= to do so until it receives an offer with an ICE restart in it. * If you're a controlling endpoint, whether to use regular or aggressive no= mination. For regular nomination, once one or more candidate pairs have be= en validated, a way for the controlling endpoint to select the one to use. = (Note that the controlling endpoint may not necessarily be the offerer, if= you receive an ice-lite offer.) -- Jonathan Lennox jonathan@vidyo.com From martin.thomson@gmail.com Thu Jun 14 13:13:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15B921F878A for ; Thu, 14 Jun 2012 13:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=-0.550, 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 8sg+0VYULgDx for ; Thu, 14 Jun 2012 13:13:51 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E089121F8786 for ; Thu, 14 Jun 2012 13:13:50 -0700 (PDT) Received: by bkty8 with SMTP id y8so2036984bkt.31 for ; Thu, 14 Jun 2012 13:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TGimI1njV7UrtaDs8jlLTeHkCr21eh2RGAyULZdzFMc=; b=vi7yi/MLhooOv3z/4qfRy3v5PaJlPTxqXEvq9jMbumAE1aX5Yf4mg9Wz/K3I9g73Qi nEPCKZH54iJcmi9Ev+uKkzpAc/mnQ/U6kqU5K647XNuFDWDBSrkVgiEqV0a8FkeqkuwA euBhTpHlS0a9YUHBfF2SgDlJR7JyOi4OUZ2K59UcPAsglclkBDCzlXYWfp9nCUzwZXsP 9tLsOdAecGSBjeINEbnMnnMTuiumGRT5ri8aW9Bxt3J3stPRJptwCAIrGW+7L2gFB/1C qDUEfrVTwvh5Um627hYcJIfuCt6PvE+MHibzkRJf/pi0vu4k+jMT8w++gq1S/W7ZZ3zK OyJA== MIME-Version: 1.0 Received: by 10.204.149.216 with SMTP id u24mr1779922bkv.36.1339704829983; Thu, 14 Jun 2012 13:13:49 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Thu, 14 Jun 2012 13:13:49 -0700 (PDT) In-Reply-To: References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com> Date: Thu, 14 Jun 2012 13:13:49 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:13:51 -0000 On 14 June 2012 12:36, Justin Uberti wrote: > For "mute", stopping sending of RTP may trigger concealment on the remote > side. We currently send silent audio when muted to prevent this. > For "hold", you are notifying the remote side (e.g. a=inactive), so it makes > sense to stop sending RTP. Since signaling takes a little while to transit the network, it makes sense for hold to act as mute (send silence) until it is accepted. I think that most users will expect hold to take immediate effect, at least from the perspective of sending of media. From matthew.kaufman@skype.net Thu Jun 14 14:41:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1866F21F84A7 for ; Thu, 14 Jun 2012 14:41:50 -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 q8easQj5qKlC for ; Thu, 14 Jun 2012 14:41:49 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 778DD21F84A6 for ; Thu, 14 Jun 2012 14:41:49 -0700 (PDT) Received: from mail178-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 21:40:41 +0000 Received: from mail178-ch1 (localhost [127.0.0.1]) by mail178-ch1-R.bigfish.com (Postfix) with ESMTP id A9E2C440523; Thu, 14 Jun 2012 21:40:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh87h2a8h668h839h944hd25he96hf0ah) Received-SPF: pass (mail178-ch1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail178-ch1 (localhost.localdomain [127.0.0.1]) by mail178-ch1 (MessageSwitch) id 1339710038373829_10052; Thu, 14 Jun 2012 21:40:38 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail178-ch1.bigfish.com (Postfix) with ESMTP id 59C07E0049; Thu, 14 Jun 2012 21:40:38 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 21:40:37 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.76]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Thu, 14 Jun 2012 21:41:44 +0000 From: Matthew Kaufman To: Jonathan Lennox , "rtcweb@ietf.org" Thread-Topic: [rtcweb] What I think we need to do about ICE Thread-Index: AQHNSHYOzJwHSe799kOZUoS2sPPqXJb6QI2AgAAa6oA= Date: Thu, 14 Jun 2012 21:41:44 +0000 Message-ID: References: <73851E92-3D9D-43FE-8F51-C893D8D755AA@vidyo.com> In-Reply-To: <73851E92-3D9D-43FE-8F51-C893D8D755AA@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [rtcweb] What I think we need to do about ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:41:50 -0000 Jonathan Lennox: > That said, ICE says that once you're in "ICE Completed" state, the only w= ay to change a component's selected candidate pair is by doing an ICE resta= rt. > Trickle candidates are equivalent to candidates sent in an updated offer = or answer in the "ICE Running" state (9.1.2.1 / 9.2.2.1). Thus, they're ig= nored once an endpoint enters "ICE Completed" state. These sound like great reasons to not bake a full ICE state machine into th= e browser but instead provide primatives to Javascript which allow for the = sending and receiving of STUN connectivity tests. That way an endpoint talk= ing to another one that didn't care about this "ICE Completed" state could = add innovation around rapid recovery from network changes. Matthew Kaufman From andrew.hutton@siemens-enterprise.com Fri Jun 15 01:17:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBA821F8503 for ; Fri, 15 Jun 2012 01:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 e1BMkzikrROD for ; Fri, 15 Jun 2012 01:17:34 -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 49A8221F8551 for ; Fri, 15 Jun 2012 01:17:32 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9252723F05BE; Fri, 15 Jun 2012 10:17:31 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Fri, 15 Jun 2012 10:17:31 +0200 From: "Hutton, Andrew" To: Martin Thomson , Justin Uberti Thread-Topic: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) Thread-Index: AQHNSi8V99bC4xTMh0uQV/Y6A7X7Fpb6FDaAgAAKT4CAAOk80A== Date: Fri, 15 Jun 2012 08:17:31 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0264A0@MCHP04MSX.global-ad.net> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com> In-Reply-To: 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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 08:17:35 -0000 On 14 June 2012 22:14 Martin Thomson wrote: >=20 > Since signaling takes a little while to transit the network, it makes > sense for hold to act as mute (send silence) until it is accepted. I > think that most users will expect hold to take immediate effect, at > least from the perspective of sending of media. This is debatable and relates to the discussion about when to apply any cha= nge to the session description really the change should probably not be app= lied until the answer is received otherwise it might be necessary to restor= e the previous session description depending on the result of the offer/ans= wer exchange. I would say don't apply the change until the answer is recei= ved. Regards Andy > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Fri Jun 15 03:34:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEB121F85B8 for ; Fri, 15 Jun 2012 03:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_41=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 Hjj-+fZXVusM for ; Fri, 15 Jun 2012 03:34:36 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 651CF21F85A1 for ; Fri, 15 Jun 2012 03:34:35 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-57-4fdb0fb9633f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C5.A2.00702.9BF0BDF4; Fri, 15 Jun 2012 12:34:34 +0200 (CEST) Received: from [150.132.142.244] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Fri, 15 Jun 2012 12:34:33 +0200 Message-ID: <4FDB0FB7.7000809@ericsson.com> Date: Fri, 15 Jun 2012 12:34:31 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Hutton, Andrew" References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com>, <8A7A43A8-90B0-46E0-83C4-E950BC4A3B2C@siemens-enterprise.com> In-Reply-To: <8A7A43A8-90B0-46E0-83C4-E950BC4A3B2C@siemens-enterprise.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvre4u/tv+Btt2sVqc7etit9g6Vchi 7b92dgdmjwWbSj2WLPnJ5HHj9nvmAOYoLpuU1JzMstQifbsEroyv+06zF+y3qXjR84O1gXGd ZhcjJ4eEgInEgsWH2SFsMYkL99azdTFycQgJnGKUuHDrLguEs5ZRYm5TFwtIFa+AtsT2Nc/Y QGwWAVWJx59fMYHYbAI2Emu7pwDZHByiAmESqx9oQJQLSpyc+QSsVUTAWuLD/BZmEJtZwE/i 7rcfYLawQKHE/UkHWSF2fWSV+NB6kx1kDqeAl8TWRmuIeluJC3Ous0DY8hLb384B6xUS0JV4 9/oe6wRGwVlI1s1C0jILScsCRuZVjMK5iZk56eXmeqlFmcnFxfl5esWpmxiBoXtwy2+DHYyb 7osdYpTmYFES59VT3e8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFT7L+iWV9qrK38tM6Y ZW6VYh81/r1duu3MTPlv72zbN9uzay/4eP7Jz701DqFnr4T+K9md/kzDZe7id0sUHR0vPPS6 uXrSw1pHXtWKzzbaUm9Y2m7lOujU7tt3r0DgQHV6s2BP8mRnF/9o+2MXPvUoS5xd/7dwlpuV 3W2egxX2Cy+t6FheJKDEUpyRaKjFXFScCABaCvjvKwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 10:34:37 -0000 On 06/14/2012 10:01 PM, Hutton, Andrew wrote: > I agree with Justin that mute is a local action and should not stop the > RTP or change the state of the remote track. > > Regards > Andy First, a short explanation of (my understanding of) what is in the API now: * each track has a muted/unmuted and a enabled/disabled state * enable state can be controlled by the application * muted state can only be controlled by the browser * muted overrides enabled (so a track that is enabled will still not play if it is muted) The idea is that "mute" state is out of the control of the app (so the browser can override - and the user if the browser chrome allows). There has been some discussion indicating that the above is not sufficient and that we need to add more. I think we're talking about different "mutes" in this thread. One that is that you mute using e.g. a button on your headset. This would lead to audio samples with amplitude of zero being generated. This should not change any state on the track (locally or remotely) IMO, and silence/cn should be sent in the RTP. Another is that the app has a "mute" button. Clicking this would (depending of the app) lead to the corresponding track being "disabled" in the local MediaStream. For the remote MediaStream, this is basically the same as "mute in the browser chrome" in the local case (since the source stops producing data), and I think the state there should change to "muted". A third is that you mute the device via the browser chrome (I assume this possibility will exist). In this case the track state changes to muted, and I really think this should propagate to the other end of a PeerConnection. Stefan > > > > On 14 Jun 2012, at 20:37, "Justin Uberti" > wrote: > >> For "mute", stopping sending of RTP may trigger concealment on the >> remote side. We currently send silent audio when muted to prevent this. >> For "hold", you are notifying the remote side (e.g. a=inactive), so it >> makes sense to stop sending RTP. >> >> On Thu, Jun 14, 2012 at 9:10 AM, Stefan Hakansson LK >> > > wrote: >> >> On 06/14/2012 11:21 AM, Harald Alvestrand wrote: >> >> Changing the subject line again, since we're discussing how to do >> mute, not whether to do it..... >> >> On 06/14/2012 11:15 AM, Hutton, Andrew wrote: >> >> On 13 June 2012 15:37 Stefan Hakansson wrote: >> >> This is my personal understanding: >> >> - the API (and this part has been there for a long >> time) allows >> the application to disable/enable individual tracks of >> MediaStreams - So say you have a MediaStream (one >> audio track, >> one video track in this example) that is rendered >> using a video >> element; disabling audio would lead to silence, >> disabling video >> to that the video stops - The question is: what should >> happen if >> the MediaStream is connected to a PeerConnection and >> sent to a >> peer? - using recvonly does not seem appropriate as >> that would >> stop all ssrc:s belonging to the same m-line - and the >> app only >> disabled one - one option could be to simply stop >> sending the RTP >> packets for this track. I don't know how reliable that >> would be. >> >> In the case of outgoing media then I think mute should simply >> disconnect the source (e.g. microphone) and there is no >> impact on >> RTP other than depending on the codec silence will be >> transmitted >> or SID frame etc. There is also no impact on RTCP which >> continues. >> >> This is different to setting the direction to be recvonly >> which >> would completely stop the outgoing RTP packets and would >> normally >> be signaled to the remote party. This should of course be >> achieved >> using setLocalDescription. >> >> >> Just to add to the complexity of the "mute" case: >> >> When an audio stream is muted, should there be comfort noise >> sent? If >> yes, what should determine the noise level? >> >> >> To me it feels as that ideally we should stop sending RTP (and >> make the other end know that the track is disabled). If we go to >> comfort noise state, the track in the MediaStream at the other end >> would still be active (even though what is played could be very >> low level comfort noise), but to reflect the local state the >> remote track should go to "muted", shouldn't it? >> >> >> >> >> (people who've never had to deal with comfort noise can safely >> tune >> out at this point) >> >> >> >> - I think there has been proposals signaling this in >> SDP or in >> RTCP, but I don't think there was ever any conclusion >> >> If we are talking about a local mute then I don't see any >> need to >> signal this but again this is different to changing the >> direction >> attribute in SDP. >> >> For the other part, muting incoming media, this is >> simple: the >> app (at receiving browser) could just disable the >> tracks it wants >> in the incoming MediaStreams. A related question is if >> this >> should be signaled back to the sender (so it could >> stop sending). >> This is essentially a question of >> efficiency/optimization, and >> nothing stops the app from signaling that now using an app >> specific protocol (perhaps carried over the data >> channel), but >> perhaps this should be brought into SDP or RTCP. >> >> If the application wants to ask the remote party to pause >> sending >> of RTP then it should surely do this in SDP by setting the >> direction attribute appropriately (i.e. sendonly or inactive). >> >> Regards Andy >> >> _________________________________________________ rtcweb >> mailing >> list rtcweb@ietf.org >> https://www.ietf.org/mailman/__listinfo/rtcweb >> >> >> >> _________________________________________________ rtcweb >> mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/__listinfo/rtcweb >> >> >> >> _________________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/__listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Fri Jun 15 03:34:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E3D21F85DA for ; Fri, 15 Jun 2012 03:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 9LB0-5AfnKC1 for ; Fri, 15 Jun 2012 03:34:50 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9821F85D8 for ; Fri, 15 Jun 2012 03:34:49 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-b1-4fdb0fc8bc48 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 90.5C.11869.8CF0BDF4; Fri, 15 Jun 2012 12:34:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.62]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 15 Jun 2012 12:34:48 +0200 From: Christer Holmberg To: "Hutton, Andrew" , Martin Thomson , Justin Uberti Date: Fri, 15 Jun 2012 12:34:46 +0200 Thread-Topic: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) Thread-Index: AQHNSi8V99bC4xTMh0uQV/Y6A7X7Fpb6FDaAgAAKT4CAAOk80IAAJ6xw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C474C910D@ESESSCMS0356.eemea.ericsson.se> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0264A0@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0264A0@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvre4J/tv+Bqv/Cluc7etit9g6Vcji 2pl/jBZr/7WzO7B47Jx1l91jwaZSjyVLfjJ53Lj9njmAJYrLJiU1J7MstUjfLoErY+PdHawF 3/gqti+cxNbAuJCni5GTQ0LARGLB04csELaYxIV769lAbCGBU4wSv1fKQtgLGCX2n+PqYuTg YBOwkOj+p93FyMUhItDDKPF/3WRGkBpmAXWJO4vPsYPUsAioSvRNSwQJCwsUS0x91gE2UkSg ROLkm1ZGCNtNomPdXGYQm1cgXKLj2F9GkJlCAhfZJKYtb2cFSXAK+EqsvwtxGyPQbd9PrWGC 2CUucevJfCaImwUkluw5zwxhi0q8fPyPFaJeVOJO+3qo2/QkbkydwgZha0ssW/gaarGgxMmZ T1gmMIrNQjJ2FpKWWUhaZiFpWcDIsopRODcxMye93EgvtSgzubg4P0+vOHUTIzC6Dm75rbqD 8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLglGpgXHx7ypqL4XNUFq27 bP3I7NDkU08tUo0OW2/rM188J0B3at4mzRi+stsMydc7+F9M7H6WPvnSX4FDcy3Xn+H1W+O7 3V4p9+T9AN0vnrYfeZiau9ODr7A85bvu+n/yrCkn5p//GTmde+PDbVNvTYsTEpduDLrzbf6+ H8e6LVlmVu3xYkn7NevTzSQlluKMREMt5qLiRABvGALifAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 10:34:50 -0000 I'd say it's an implementation issue. If I want to put a call on hold, I wi= ll stop sending media no matter what the response to the updated offer is. Also, as we discussed in SIPCORE when working on the re-INVITE handling spe= c, clients may not even be able to fallback to the before-the-new-offer-was= -sent state (probably not an issue for hold, but in general). However, I don't think it's up to us to specify how services work :) We sh= ould focus on what happens when no media is sent - for whatever reason. Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: 15. kes=E4kuuta 2012 11:18 To: Martin Thomson; Justin Uberti Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf= -rtcweb-use-cases-and-requirements-07) On 14 June 2012 22:14 Martin Thomson wrote: >=20 > Since signaling takes a little while to transit the network, it makes=20 > sense for hold to act as mute (send silence) until it is accepted. I=20 > think that most users will expect hold to take immediate effect, at=20 > least from the perspective of sending of media. This is debatable and relates to the discussion about when to apply any cha= nge to the session description really the change should probably not be app= lied until the answer is received otherwise it might be necessary to restor= e the previous session description depending on the result of the offer/ans= wer exchange. I would say don't apply the change until the answer is recei= ved. Regards Andy > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Fri Jun 15 03:36:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A855A21F8417 for ; Fri, 15 Jun 2012 03:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 TEvUO2Euiwxf for ; Fri, 15 Jun 2012 03:36:35 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCE321F85A1 for ; Fri, 15 Jun 2012 03:36:34 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-7a-4fdb1031714c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 99.9C.11869.1301BDF4; Fri, 15 Jun 2012 12:36:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.62]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 15 Jun 2012 12:36:33 +0200 From: Christer Holmberg To: "Hutton, Andrew" , Martin Thomson , Justin Uberti Date: Fri, 15 Jun 2012 12:36:32 +0200 Thread-Topic: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) Thread-Index: AQHNSi8V99bC4xTMh0uQV/Y6A7X7Fpb6FDaAgAAKT4CAAOk80IAAJ6xwgAABYOA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C474C9111@ESESSCMS0356.eemea.ericsson.se> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0264A0@MCHP04MSX.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C474C910D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C474C910D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvra6hwG1/gz1T9CzO9nWxW2ydKmRx 7cw/Rou1/9rZHVg8ds66y+6xYFOpx5IlP5k8btx+zxzAEsVlk5Kak1mWWqRvl8CV0Td7GlNB j0hF18VFzA2MVwW6GDk5JARMJG7f72KCsMUkLtxbz9bFyMUhJHCKUWLvhP2sEM4CRomeEx+B MhwcbAIWEt3/tEHiIgI9jBL/101mBOlmFlCXuLP4HDuIzSKgKvGraRLYVGGBYonjv3+ygdgi AiUSt5vvs0LYfhKPW94wg8zkFQiXmNyZBLFrPrvE3d9bwHo5BSIk5n/fCmYzAl33/dQaJohd 4hK3nsyHulpAYsme88wQtqjEy8f/WCHqRSXutK+Huk1P4sbUKWwQtrbEsoWvwep5BQQlTs58 wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsYgRF2cMtv1R2M d86JHGKU5mBREue13rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjmLKNfJnBrXtH3sYu npuhI+n16ZnEO8PWA/p+JW/e/RLleLTBN2nb5JcGbbpcJ4uCeM1/b124aNp1v7a/10xkHhy/ aHsh85DYHReum5OVMh4pTF/y3anKXZ/LcFkEj4D90rf3m45Y+XP90eV5zBHcL593lzlyTue/ CQviv9y46em36q/2DdF0JZbijERDLeai4kQAf1XoBX4CAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 10:36:35 -0000 I think we DO, however, need to specify what happens if a new offer is reje= cted, and if the browser is not able to fallback to the previous state. Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 15. kes=E4kuuta 2012 13:35 To: Hutton, Andrew; Martin Thomson; Justin Uberti Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf= -rtcweb-use-cases-and-requirements-07) I'd say it's an implementation issue. If I want to put a call on hold, I wi= ll stop sending media no matter what the response to the updated offer is. Also, as we discussed in SIPCORE when working on the re-INVITE handling spe= c, clients may not even be able to fallback to the before-the-new-offer-was= -sent state (probably not an issue for hold, but in general). However, I don't think it's up to us to specify how services work :) We sh= ould focus on what happens when no media is sent - for whatever reason. Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: 15. kes=E4kuuta 2012 11:18 To: Martin Thomson; Justin Uberti Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf= -rtcweb-use-cases-and-requirements-07) On 14 June 2012 22:14 Martin Thomson wrote: >=20 > Since signaling takes a little while to transit the network, it makes=20 > sense for hold to act as mute (send silence) until it is accepted. I=20 > think that most users will expect hold to take immediate effect, at=20 > least from the perspective of sending of media. This is debatable and relates to the discussion about when to apply any cha= nge to the session description really the change should probably not be app= lied until the answer is received otherwise it might be necessary to restor= e the previous session description depending on the result of the offer/ans= wer exchange. I would say don't apply the change until the answer is recei= ved. Regards Andy > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From keith.drage@alcatel-lucent.com Fri Jun 15 03:50:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8643F21F85E0 for ; Fri, 15 Jun 2012 03:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.624 X-Spam-Level: X-Spam-Status: No, score=-109.624 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_41=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 xl1bVDWLoLqJ for ; Fri, 15 Jun 2012 03:50:44 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 647CC21F85DF for ; Fri, 15 Jun 2012 03:50:44 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5FAoUcj028876 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 15 Jun 2012 12:50:40 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 15 Jun 2012 12:50:39 +0200 From: "DRAGE, Keith (Keith)" To: Stefan Hakansson LK , "Hutton, Andrew" Date: Fri, 15 Jun 2012 12:50:37 +0200 Thread-Topic: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) Thread-Index: Ac1K4oOHQpwJpX+6Q96wVMrLEN6t1gAAZYYg Message-ID: References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com>, <8A7A43A8-90B0-46E0-83C4-E950BC4A3B2C@siemens-enterprise.com> <4FDB0FB7.7000809@ericsson.com> In-Reply-To: <4FDB0FB7.7000809@ericsson.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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 10:50:45 -0000 I agree it is important to agree on what resources are released (and theref= ore made available for some other purpose) as a result of the action. This = confusion has existed ever since the PSTN invented a hold service. Is the function merely to mute the transducers locally, or is the function = to make resources (any of media, signaling, transducers, etc) available for= some other purpose. Regards Keith -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Stefan Hakansson LK Sent: 15 June 2012 11:35 To: Hutton, Andrew Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf= -rtcweb-use-cases-and-requirements-07) On 06/14/2012 10:01 PM, Hutton, Andrew wrote: > I agree with Justin that mute is a local action and should not stop the > RTP or change the state of the remote track. > > Regards > Andy First, a short explanation of (my understanding of) what is in the API now: * each track has a muted/unmuted and a enabled/disabled state * enable state can be controlled by the application * muted state can only be controlled by the browser * muted overrides enabled (so a track that is enabled will still not=20 play if it is muted) The idea is that "mute" state is out of the control of the app (so the=20 browser can override - and the user if the browser chrome allows). There=20 has been some discussion indicating that the above is not sufficient and=20 that we need to add more. I think we're talking about different "mutes" in this thread. One that is that you mute using e.g. a button on your headset. This=20 would lead to audio samples with amplitude of zero being generated. This=20 should not change any state on the track (locally or remotely) IMO, and=20 silence/cn should be sent in the RTP. Another is that the app has a "mute" button. Clicking this would=20 (depending of the app) lead to the corresponding track being "disabled"=20 in the local MediaStream. For the remote MediaStream, this is basically=20 the same as "mute in the browser chrome" in the local case (since the=20 source stops producing data), and I think the state there should change=20 to "muted". A third is that you mute the device via the browser chrome (I assume=20 this possibility will exist). In this case the track state changes to=20 muted, and I really think this should propagate to the other end of a=20 PeerConnection. Stefan > > > > On 14 Jun 2012, at 20:37, "Justin Uberti" > wrote: > >> For "mute", stopping sending of RTP may trigger concealment on the >> remote side. We currently send silent audio when muted to prevent this. >> For "hold", you are notifying the remote side (e.g. a=3Dinactive), so it >> makes sense to stop sending RTP. >> >> On Thu, Jun 14, 2012 at 9:10 AM, Stefan Hakansson LK >> > > wrote: >> >> On 06/14/2012 11:21 AM, Harald Alvestrand wrote: >> >> Changing the subject line again, since we're discussing how to d= o >> mute, not whether to do it..... >> >> On 06/14/2012 11:15 AM, Hutton, Andrew wrote: >> >> On 13 June 2012 15:37 Stefan Hakansson wrote: >> >> This is my personal understanding: >> >> - the API (and this part has been there for a long >> time) allows >> the application to disable/enable individual tracks of >> MediaStreams - So say you have a MediaStream (one >> audio track, >> one video track in this example) that is rendered >> using a video >> element; disabling audio would lead to silence, >> disabling video >> to that the video stops - The question is: what should >> happen if >> the MediaStream is connected to a PeerConnection and >> sent to a >> peer? - using recvonly does not seem appropriate as >> that would >> stop all ssrc:s belonging to the same m-line - and the >> app only >> disabled one - one option could be to simply stop >> sending the RTP >> packets for this track. I don't know how reliable that >> would be. >> >> In the case of outgoing media then I think mute should simpl= y >> disconnect the source (e.g. microphone) and there is no >> impact on >> RTP other than depending on the codec silence will be >> transmitted >> or SID frame etc. There is also no impact on RTCP which >> continues. >> >> This is different to setting the direction to be recvonly >> which >> would completely stop the outgoing RTP packets and would >> normally >> be signaled to the remote party. This should of course be >> achieved >> using setLocalDescription. >> >> >> Just to add to the complexity of the "mute" case: >> >> When an audio stream is muted, should there be comfort noise >> sent? If >> yes, what should determine the noise level? >> >> >> To me it feels as that ideally we should stop sending RTP (and >> make the other end know that the track is disabled). If we go to >> comfort noise state, the track in the MediaStream at the other end >> would still be active (even though what is played could be very >> low level comfort noise), but to reflect the local state the >> remote track should go to "muted", shouldn't it? >> >> >> >> >> (people who've never had to deal with comfort noise can safely >> tune >> out at this point) >> >> >> >> - I think there has been proposals signaling this in >> SDP or in >> RTCP, but I don't think there was ever any conclusion >> >> If we are talking about a local mute then I don't see any >> need to >> signal this but again this is different to changing the >> direction >> attribute in SDP. >> >> For the other part, muting incoming media, this is >> simple: the >> app (at receiving browser) could just disable the >> tracks it wants >> in the incoming MediaStreams. A related question is if >> this >> should be signaled back to the sender (so it could >> stop sending). >> This is essentially a question of >> efficiency/optimization, and >> nothing stops the app from signaling that now using an a= pp >> specific protocol (perhaps carried over the data >> channel), but >> perhaps this should be brought into SDP or RTCP. >> >> If the application wants to ask the remote party to pause >> sending >> of RTP then it should surely do this in SDP by setting the >> direction attribute appropriately (i.e. sendonly or inactive= ). >> >> Regards Andy >> >> _________________________________________________ rtcweb >> mailing >> list rtcweb@ietf.org >> https://www.ietf.org/mailman/__listinfo/rtcweb >> >> >> >> _________________________________________________ rtcweb >> mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/__listinfo/rtcweb >> >> >> >> _________________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/__listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Jun 15 13:22:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1215A21F8539 for ; Fri, 15 Jun 2012 13:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.039 X-Spam-Level: X-Spam-Status: No, score=-4.039 tagged_above=-999 required=5 tests=[AWL=-0.440, 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 v6oRASNahYYM for ; Fri, 15 Jun 2012 13:22:13 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1279221F851B for ; Fri, 15 Jun 2012 13:22:12 -0700 (PDT) Received: by bkty8 with SMTP id y8so3029990bkt.31 for ; Fri, 15 Jun 2012 13:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5rRBcp6Ng1RQxlN88/ICxOsFfPpxhtMP6b4jTLhmuRg=; b=B5q3Dw8FHf0csMOQMs0vTjRgSdx1jiINvOnCK0H4qTD6LxWh/gBHOgY0VFFl7bXw+f l+PL6pbtc3CgDXGQxQAmdmBZx1KmwFVPGL9nhALFyth9ShvGrY9+ye8Iacn4zHW3X4wv EcnfwFnNf9zLjM66hrE58EyHpYffnW/CC8JG9DCLTv3BNZ/B9B76q43sntyPmVX5faCQ oZnXHDrunoj+8LVLYoP6ViqTc0TX5sXZz+6BBb7yma8pMtGA8digmAJ0/rnujJUlkBvE x+WUpvkXAN0THj9HYd6yvDyNocLquo3XYnM0b+cvWSw2k2JFAcq4wJPj4TZNf6GaaHJ1 1FCA== MIME-Version: 1.0 Received: by 10.204.128.149 with SMTP id k21mr3323746bks.42.1339791731910; Fri, 15 Jun 2012 13:22:11 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Fri, 15 Jun 2012 13:22:11 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C474C910D@ESESSCMS0356.eemea.ericsson.se> References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0264A0@MCHP04MSX.global-ad.net> <7F2072F1E0DE894DA4B517B93C6A05852C474C910D@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 15 Jun 2012 13:22:11 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 20:22:14 -0000 On 15 June 2012 03:34, Christer Holmberg wrote: > I don't think it's up to us to specify how services work :) We should focus on what happens when no media is sent - for whatever reason. Take that and frame it. From randell-ietf@jesup.org Fri Jun 15 13:42:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FDE21F854A for ; Fri, 15 Jun 2012 13:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSkKwU3jWPT6 for ; Fri, 15 Jun 2012 13:42:35 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5940B21F8549 for ; Fri, 15 Jun 2012 13:42:35 -0700 (PDT) Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SfdLm-00018O-Ga for rtcweb@ietf.org; Fri, 15 Jun 2012 15:42:34 -0500 Message-ID: <4FDB9E20.8070408@jesup.org> Date: Fri, 15 Jun 2012 16:42:08 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0223ED@MCHP04MSX.global-ad.net> <4FD89773.3090506@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF02594D@MCHP04MSX.global-ad.net> <4FD9AD1E.6060504@alvestrand.no> <4FD9E2BE.2080907@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Mute implementations (Re: More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 20:42:36 -0000 On 6/14/2012 3:36 PM, Justin Uberti wrote: > For "mute", stopping sending of RTP may trigger concealment on the > remote side. We currently send silent audio when muted to prevent this. > For "hold", you are notifying the remote side (e.g. a=inactive), so it > makes sense to stop sending RTP. I would also suggest that for video-mute that instead of stopping video or sending black, the application should send a "mute image". This could be done by changing the video source to be a fixed image (or small looped animation from a