From nobody Fri Oct 3 00:44:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9261A00B8 for ; Fri, 3 Oct 2014 00:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3nYdmsU2Umx for ; Fri, 3 Oct 2014 00:44:22 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 937F01ACFCD for ; Fri, 3 Oct 2014 00:44:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8E5117C3B92 for ; Fri, 3 Oct 2014 09:44:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 784ALGmkKI39 for ; Fri, 3 Oct 2014 09:44:19 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:cc66:bf92:2c4d:4dc6] (unknown [IPv6:2001:470:de0a:27:cc66:bf92:2c4d:4dc6]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7D6BE7C3B3A for ; Fri, 3 Oct 2014 09:44:19 +0200 (CEST) Message-ID: <542E53D2.5040500@alvestrand.no> Date: Fri, 03 Oct 2014 09:44:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/L5KVQAQbMzjvalEhvDqhEEHOFdU Subject: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Oct 2014 07:44:24 -0000 After all the feedback, I've taken another whack at this. It seems that the term "WebRTC endpoint" is already used widely enough that it's worth continuing to use it. So I ended up with the following suggested text for -overview's definitions. Comments? If this seems OK, I'll emit another -overview next week with these definitions. -------------------------- o A WebRTC User Agent (also called an UA or browser) is something that conforms to both the protocol specification and the Javascript API defined above. o A WebRTC device is something that conforms to the protocol specification, but does not claim to implement the Javascript API. o A WebRTC endpoint is either a WebRTC UA or a WebRTC device. o A WebRTC-compatible endpoint is an endpoint that is capable of successfully communicating with a WebRTC endpoint, but may fail to meet some requirement of the WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others. o A WebRTC gateway is a WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities. ----------------------------- FOR TRANSPORT: A WebRTC-compatible endpoint is capable of inititating or accepting a session with a WebRTC endpoint. The following requirements on a WebRTC endpoint are not required for such success: - Support for full ICE. If the endpoint is only ever going to be attached to the public Internet, it does not need to be able to fix its own external address; ICE-Lite is enough. - Support for the full suite of MTI codecs for a WebRTC endpoint. In particular, audio gateways that connect to native G.711 networks may choose to implement G.711 and not implement Opus. - Offering BUNDLE or RTCP-MUX - Using MSID in its offers or answers Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used. From nobody Fri Oct 3 04:23:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB851AD034 for ; Fri, 3 Oct 2014 04:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx2itEITCbLY for ; Fri, 3 Oct 2014 04:23:14 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0271AD038 for ; Fri, 3 Oct 2014 04:23:13 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 06DE3E1E0F5F4; Fri, 3 Oct 2014 11:23:11 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s93BNBqQ005146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 07:23:12 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 07:23:10 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Definitions of WebRTC entities Thread-Index: AQHP3t3fwDhKFsxf6EKP0BfcGg46m5weOOOA Date: Fri, 3 Oct 2014 11:23:10 +0000 Message-ID: References: <542E53D2.5040500@alvestrand.no> In-Reply-To: <542E53D2.5040500@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lKSzWSIgWL5ExgZGUGPMcAd7NmM Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Oct 2014 11:23:15 -0000 > o A WebRTC gateway is a WebRTC-compatible endpoint that mediates > media traffic to non-WebRTC entities. > Note that support for DTLS, ICE and TURN ARE required for a > WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be > used. [Raju] Though a typical WebRTC-compatible endpoint requires TURN, I don't t= hink WebRTC gateway requires TURN handling. TURN should probably be tied to= the use of full ICE or private ip; if you have public ip and use ice-lite = then TURN support is not required. BR Raju From nobody Fri Oct 3 05:01:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5107C1A0300 for ; Fri, 3 Oct 2014 05:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjXyPbsK720A for ; Fri, 3 Oct 2014 05:01:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A061A0307 for ; Fri, 3 Oct 2014 05:01:23 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-41-542e90116606 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B4.96.21334.1109E245; Fri, 3 Oct 2014 14:01:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Fri, 3 Oct 2014 14:01:21 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Definitions of WebRTC entities Thread-Index: AQHP3t3ehH0V0UJNhEaGpnZRIRprGZweQ+vQ Date: Fri, 3 Oct 2014 12:01:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> References: <542E53D2.5040500@alvestrand.no> In-Reply-To: <542E53D2.5040500@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja7gBL0Qg/nbzS2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGXca+AseCJVcejmfuYGxnmiXYycHBICJhL7 j81gg7DFJC7cWw9kc3EICRxllNg7ZQYjhLOYUaJvxVWmLkYODjYBC4nuf9ogDSICwRK9z98z gtjCQIN2ztvECBE3leiadR/KNpI4f2MbC4jNIqAiMW/ZNVYQm1fAV2LL33YmEFtIQEdi98SL YHFOAV2JlcchDmIEOuj7qTVgNcwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghbCWJHxsusUDU 60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcXFuupGx XmpRZnJxcX6eXl5qySZGYJQc3PJbdwfj6teOhxgFOBiVeHgVmPVChFgTy4orcw8xSnOwKInz Ljo3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY2duuo/L06LtzetNmc5NyFKUCX7ydxEf b6B13oZkC52snIOXZONe8n/Yqvl8ZVRCyj+Gy50HWGYaHsyxSqjX/C2SpPefz2hbC8s9R92v nXmFyUcmr4hj/6L1mlfgr1KNi+X+BI98nqIrWjWhlSvurjZNXskZ+PNTQcLpc/kGmR6hC195 GucosRRnJBpqMRcVJwIAEcbXwXMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AgRSOkmlrt2ruYnhakEAXcpYoHg Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Oct 2014 12:01:27 -0000 Hi, First, I personally see no need for all these definitions. I think it would be enough to have: - WebRTC endpoint (e.g. a browser) - WebRTC-compatible endpoint (e.g. a gateway) If people really think we need more, I won't argue against. I just think it= becomes very messy, and people WILL end up using the wrong terminology :) Second, you say: "Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compat= ible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used." You already in the bullet list said support of ICE lite, so the text is con= flicting.=20 I am not sure what you mean by "support for TURN". An ICE lite endpoint wil= l not create TURN candidates etc. Of course, it may receive media via a TUR= N server. What do you mean by "support for DTLS"? I think you need to be a little mor= e specific (later you do mention DTLS-SRTP in case of RTP). Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: 3. lokakuuta 2014 10:44 To: rtcweb@ietf.org Subject: [rtcweb] Definitions of WebRTC entities After all the feedback, I've taken another whack at this. It seems that the term "WebRTC endpoint" is already used widely enough that= it's worth continuing to use it. So I ended up with the following suggeste= d text for -overview's definitions. Comments? If this seems OK, I'll emit another -overview next week with these definiti= ons. -------------------------- o A WebRTC User Agent (also called an UA or browser) is something that= conforms to both the protocol specification and the Javascript API defined= above. o A WebRTC device is something that conforms to the protocol specification, but does not claim to implement the Javascript API. o A WebRTC endpoint is either a WebRTC UA or a WebRTC device. o A WebRTC-compatible endpoint is an endpoint that is capable of succe= ssfully communicating with a WebRTC endpoint, but may fail to meet some req= uirement of the WebRTC endpoint. This may limit where in the network such a= n endpoint can be attached, or may limit the security guarantees that it of= fers to others. o A WebRTC gateway is a WebRTC-compatible endpoint that mediates media= traffic to non-WebRTC entities. ----------------------------- FOR TRANSPORT: A WebRTC-compatible endpoint is capable of inititating or accepting a sessi= on with a WebRTC endpoint. The following requirements on a WebRTC endpoint = are not required for such success: - Support for full ICE. If the endpoint is only ever going to be attached t= o the public Internet, it does not need to be able to fix its own external = address; ICE-Lite is enough. - Support for the full suite of MTI codecs for a WebRTC endpoint. In partic= ular, audio gateways that connect to native G.711 networks may choose to im= plement G.711 and not implement Opus. - Offering BUNDLE or RTCP-MUX - Using MSID in its offers or answers Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatib= le endpoint, and if RTP is used at all, DTLS-SRTP MUST be used. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Oct 3 05:47:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6521A03A8 for ; Fri, 3 Oct 2014 05:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRNVbw0xuQmK for ; Fri, 3 Oct 2014 05:47:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 570D41A036F for ; Fri, 3 Oct 2014 05:47:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6C7F07C4326; Fri, 3 Oct 2014 14:47:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS30MVRid-Gq; Fri, 3 Oct 2014 14:47:33 +0200 (CEST) Received: from [10.243.30.177] (178-94-11.connect.netcom.no [176.11.94.178]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8227A7C42F0; Fri, 3 Oct 2014 14:47:33 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----RSEX718EAVL7B6OVA9TBBOLOWWQFWH" Content-Transfer-Encoding: 8bit From: Harald Alvestrand Date: Fri, 03 Oct 2014 14:47:30 +0200 To: Christer Holmberg , "rtcweb@ietf.org" Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/70SzI-3seNraKEjGQNY3dtb_9RI Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Oct 2014 12:47:40 -0000 ------RSEX718EAVL7B6OVA9TBBOLOWWQFWH Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Yup, turn is wrong. And ice needs to be made more precise - point is, without any ice, things will not work at all. DTLS: A webrtc endpoint either uses data channels, which require dtls, or rtp, whuch requires DTLS-srtp, which requires dtls, so I figured it was safe to say that dtls was required. Den 3. oktober 2014 14:01:20 CEST, skrev Christer Holmberg : >Hi, > >First, I personally see no need for all these definitions. > >I think it would be enough to have: > >- WebRTC endpoint (e.g. a browser) >- WebRTC-compatible endpoint (e.g. a gateway) > >If people really think we need more, I won't argue against. I just >think it becomes very messy, and people WILL end up using the wrong >terminology :) > > >Second, you say: > > "Note that support for DTLS, ICE and TURN ARE required for a >WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST >be used." > >You already in the bullet list said support of ICE lite, so the text is >conflicting. > >I am not sure what you mean by "support for TURN". An ICE lite endpoint >will not create TURN candidates etc. Of course, it may receive media >via a TURN server. > >What do you mean by "support for DTLS"? I think you need to be a little >more specific (later you do mention DTLS-SRTP in case of RTP). > >Regards, > >Christer > > > > >-----Original Message----- >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >Alvestrand >Sent: 3. lokakuuta 2014 10:44 >To: rtcweb@ietf.org >Subject: [rtcweb] Definitions of WebRTC entities > >After all the feedback, I've taken another whack at this. > >It seems that the term "WebRTC endpoint" is already used widely enough >that it's worth continuing to use it. So I ended up with the following >suggested text for -overview's definitions. > >Comments? >If this seems OK, I'll emit another -overview next week with these >definitions. > >-------------------------- > >o A WebRTC User Agent (also called an UA or browser) is something that >conforms to both the protocol specification and the Javascript API >defined above. > > o A WebRTC device is something that conforms to the protocol > specification, but does not claim to implement the Javascript API. > > o A WebRTC endpoint is either a WebRTC UA or a WebRTC device. > >o A WebRTC-compatible endpoint is an endpoint that is capable of >successfully communicating with a WebRTC endpoint, but may fail to meet >some requirement of the WebRTC endpoint. This may limit where in the >network such an endpoint can be attached, or may limit the security >guarantees that it offers to others. > >o A WebRTC gateway is a WebRTC-compatible endpoint that mediates media >traffic to non-WebRTC entities. > >----------------------------- > >FOR TRANSPORT: > >A WebRTC-compatible endpoint is capable of inititating or accepting a >session with a WebRTC endpoint. The following requirements on a WebRTC >endpoint are not required for such success: > >- Support for full ICE. If the endpoint is only ever going to be >attached to the public Internet, it does not need to be able to fix its >own external address; ICE-Lite is enough. >- Support for the full suite of MTI codecs for a WebRTC endpoint. In >particular, audio gateways that connect to native G.711 networks may >choose to implement G.711 and not implement Opus. >- Offering BUNDLE or RTCP-MUX >- Using MSID in its offers or answers > more> > >Note that support for DTLS, ICE and TURN ARE required for a >WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST >be used. > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------RSEX718EAVL7B6OVA9TBBOLOWWQFWH Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yup, turn is wrong. And ice needs to be made more precise - point is, without any ice, things will not work at all.

DTLS: A webrtc endpoint either uses data channels, which require dtls, or rtp, whuch requires DTLS-srtp, which requires dtls, so I figured it was safe to say that dtls was required.

Den 3. oktober 2014 14:01:20 CEST, skrev Christer Holmberg <christer.holmberg@ericsson.com>:
Hi,

First, I personally see no need for all these definitions.

I think it would be enough to have:

- WebRTC endpoint (e.g. a browser)
- WebRTC-compatible endpoint (e.g. a gateway)

If people really think we need more, I won't argue against. I just think it becomes very messy, and people WILL end up using the wrong terminology :)


Second, you say:

 "Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used."

You already in the bullet list said support of ICE lite, so the text is conflicting. 

I am not sure what you mean by "support for TURN". An ICE lite endpoint will not create TURN candidates etc. Of course, it may receive media via a TURN server.

What do you mean by "support for DTLS"? I think you need to be a little more specific (later you do mention DTLS-SRTP in case of
RTP).

Regards,

Christer




-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 3. lokakuuta 2014 10:44
To: rtcweb@ietf.org
Subject: [rtcweb] Definitions of WebRTC entities

After all the feedback, I've taken another whack at this.

It seems that the term "WebRTC endpoint" is already used widely enough that it's worth continuing to use it. So I ended up with the following suggested text for -overview's definitions.

Comments?
If this seems OK, I'll emit another -overview next week with these definitions.

--------------------------

    o  A WebRTC User Agent (also called an UA or browser) is something that conforms to both the protocol specification and the Javascript API defined above.

    o  A WebRTC device is something that conforms to the protocol
       specification, but does not
claim to implement the Javascript API.

    o  A WebRTC endpoint is either a WebRTC UA or a WebRTC device.

    o  A WebRTC-compatible endpoint is an endpoint that is capable of successfully communicating with a WebRTC endpoint, but may fail to meet some requirement of the WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others.

    o  A WebRTC gateway is a WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities.

-----------------------------

FOR TRANSPORT:

A WebRTC-compatible endpoint is capable of inititating or accepting a session with a WebRTC endpoint. The following requirements on a WebRTC endpoint are not required for such success:

- Support for full ICE. If the endpoint is only ever going to be attached to the public Internet, it does not need to be able to fix its own external address;
ICE-Lite is enough.
- Support for the full suite of MTI codecs for a WebRTC endpoint. In particular, audio gateways that connect to native G.711 networks may choose to implement G.711 and not implement Opus.
- Offering BUNDLE or RTCP-MUX
- Using MSID in its offers or answers
<should congestion cutoff requirement be in or out?> <there will be more>

Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used.



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

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------RSEX718EAVL7B6OVA9TBBOLOWWQFWH-- From nobody Fri Oct 3 10:26:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4710C1A8747 for ; Fri, 3 Oct 2014 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gpb5xWSGEd1S for ; Fri, 3 Oct 2014 10:26:17 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D69C1A8746 for ; Fri, 3 Oct 2014 10:26:16 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-fa-542edc362c66 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 25.F3.24955.63CDE245; Fri, 3 Oct 2014 19:26:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Fri, 3 Oct 2014 19:26:13 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Definitions of WebRTC entities Thread-Index: AQHP3t3ehH0V0UJNhEaGpnZRIRprGZweQ+vQ///tNQCAAG62UA== Date: Fri, 3 Oct 2014 17:26:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D465985ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja7ZHb0Qg6a/AhbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI6l9xnLpg0kbGi68lF9gbGBb2MXYwcHBIC JhIbJnp3MXICmWISF+6tZ+ti5OIQEjjKKLF/XTcLSEJIYDGjxKk3PCD1bAIWEt3/tEHCIgLB Er3P3zOC2MJAY3bO28QIETeV6Jp1H8p2kli8YCMbiM0ioCLx/utTsDivgK/ErZb5ULuWM0pc //GBGSTBKeAosfvrGlYQmxHooO+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghbCWJ Rbc/Q9XnS3xdeYcdYpmgxMmZT1gmMIrMQjJqFpKyWUjKZgG9ySygKbF+lz5EiaLElO6H7BC2 hkTrnLnsyOILGNlXMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgTG1cEtv1V3MF5+43iIUYCD UYmHV4FZL0SINbGsuDL3EKM0B4uSOO/Cc/OChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTC6 xR9srtjdmiq4Wv5kdsW3KU/NFFXe+6w4t2jZxgVcvdfYKytueMTuYc2qkw65uX+i/XXxW0+m ieQ2/2ktSJGd4Oe1JH+yV/i0JpGd3ytL6xl/2+aZtkYsadj5uLbwGPMbX1NpRz05h2mzX+9m Cg86/qeCI1OY57zj07L1QeVqh+SPfjwe0afEUpyRaKjFXFScCADV+D7+jAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IYOZtb7ODsZQTY-nEY-TM-WfVhA Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Oct 2014 17:26:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D465985ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5ZdXAsIHR1cm4gaXMgd3JvbmcuIEFuZCBpY2UgbmVlZHMgdG8gYmUgbWFkZSBtb3Jl IHByZWNpc2UgLSBwb2ludCBpcywgPndpdGhvdXQgYW55IGljZSwgdGhpbmdzIHdpbGwgbm90IHdv cmsgYXQgYWxsLg0KQWdyZWUuIEJ1dCwgSSB0aGluayB0aGUgYnVsbGV0IHRhbGtpbmcgYWJvdXQg 4oCcSUNFIGxpdGXigJ0gaXMgZW5vdWdoLg0KDQo+RFRMUzogQSB3ZWJydGMgZW5kcG9pbnQgZWl0 aGVyIHVzZXMgZGF0YSBjaGFubmVscywgd2hpY2ggcmVxdWlyZSBkdGxzLCA+b3IgcnRwLCB3aHVj aCByZXF1aXJlcyBEVExTLXNydHAsIHdoaWNoIHJlcXVpcmVzIGR0bHMsIHNvIEkgZmlndXJlZCBp dCA+d2FzIHNhZmUgdG8gc2F5IHRoYXQgZHRscyB3YXMgcmVxdWlyZWQuDQpJIHRoaW5rIGl0IHdv dWxkIGJlIGJldHRlciB0byBleHBsaWNpdGx5IGluZGljYXRlIHRoZSB1c2FnZXMgZm9yIHdoaWNo IERUTFMgbmVlZHMgdG8gYmUgc3VwcG9ydGVkLCBpZSBEVExTLVNSVFAgZm9yIFJUUCBhbmQgYXMg ZGVmaW5lZCBmb3IgZGF0YSBjaGFubmVscy4NCkJlY2F1c2UsIERUTFMgY2FuIGJlIHVzZWQgZm9y IG1hbnkgZGlmZmVyZW50IHB1cnBvc2VzLCBpbiBkaWZmZXJlbnQgd2F5cywgc28ganVzdCBzYXlp bmcg4oCcc3VwcG9ydCBEVExT4oCdIGlzIHVuY2xlYXIuDQpSZWdhcmRzLA0KQ2hyaXN0ZXINCg0K RGVuIDMuIG9rdG9iZXIgMjAxNCAxNDowMToyMCBDRVNULCBza3JldiBDaHJpc3RlciBIb2xtYmVy ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+PjoNCg0KSGksDQoNCkZpcnN0LCBJIHBlcnNvbmFsbHkgc2VlIG5vIG5l ZWQgZm9yIGFsbCB0aGVzZSBkZWZpbml0aW9ucy4NCg0KSSB0aGluayBpdCB3b3VsZCBiZSBlbm91 Z2ggdG8gaGF2ZToNCg0KLSBXZWJSVEMgZW5kcG9pbnQgKGUuZy4gYSBicm93c2VyKQ0KLSBXZWJS VEMtY29tcGF0aWJsZSBlbmRwb2ludCAoZS5nLiBhIGdhdGV3YXkpDQoNCklmIHBlb3BsZSByZWFs bHkgdGhpbmsgd2UgbmVlZCBtb3JlLCBJIHdvbid0IGFyZ3VlIGFnYWluc3QuIEkganVzdCB0aGlu ayBpdCBiZWNvbWVzIHZlcnkgbWVzc3ksIGFuZCBwZW9wbGUgV0lMTCBlbmQgdXAgdXNpbmcgdGhl IHdyb25nIHRlcm1pbm9sb2d5IDopDQoNCg0KU2Vjb25kLCB5b3Ugc2F5Og0KDQogIk5vdGUgdGhh dCBzdXBwb3J0IGZvciBEVExTLCBJQ0UgYW5kIFRVUk4gQVJFIHJlcXVpcmVkIGZvciBhIFdlYlJU Qy1jb21wYXRpYmxlIGVuZHBvaW50LCBhbmQgaWYgUlRQIGlzIHVzZWQgYXQgYWxsLCBEVExTLVNS VFAgTVVTVCBiZSB1c2VkLiINCg0KWW91IGFscmVhZHkgaW4gdGhlIGJ1bGxldCBsaXN0IHNhaWQg c3VwcG9ydCBvZiBJQ0UgbGl0ZSwgc28gdGhlIHRleHQgaXMgY29uZmxpY3RpbmcuDQoNCkkgYW0g bm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSAic3VwcG9ydCBmb3IgVFVSTiIuIEFuIElDRSBsaXRl IGVuZHBvaW50IHdpbGwgbm90IGNyZWF0ZSBUVVJOIGNhbmRpZGF0ZXMgZXRjLiBPZiBjb3Vyc2Us IGl0IG1heSByZWNlaXZlIG1lZGlhIHZpYSBhIFRVUk4gc2VydmVyLg0KDQpXaGF0IGRvIHlvdSBt ZWFuIGJ5ICJzdXBwb3J0IGZvciBEVExTIj8gSSB0aGluayB5b3UgbmVlZCB0byBiZSBhIGxpdHRs ZSBtb3JlIHNwZWNpZmljIChsYXRlciB5b3UgZG8gbWVudGlvbiBEVExTLVNSVFAgaW4gY2FzZSBv Zg0KDQpSVFApLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBIYXJhbGQgQWx2ZXN0cmFuZA0KU2VudDogMy4gbG9rYWt1dXRhIDIw MTQgMTA6NDQNClRvOiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1 YmplY3Q6IFtydGN3ZWJdIERlZmluaXRpb25zIG9mIFdlYlJUQyBlbnRpdGllcw0KDQpBZnRlciBh bGwgdGhlIGZlZWRiYWNrLCBJJ3ZlIHRha2VuIGFub3RoZXIgd2hhY2sgYXQgdGhpcy4NCg0KSXQg c2VlbXMgdGhhdCB0aGUgdGVybSAiV2ViUlRDIGVuZHBvaW50IiBpcyBhbHJlYWR5IHVzZWQgd2lk ZWx5IGVub3VnaCB0aGF0IGl0J3Mgd29ydGggY29udGludWluZyB0byB1c2UgaXQuIFNvIEkgZW5k ZWQgdXAgd2l0aCB0aGUgZm9sbG93aW5nIHN1Z2dlc3RlZCB0ZXh0IGZvciAtb3ZlcnZpZXcncyBk ZWZpbml0aW9ucy4NCg0KQ29tbWVudHM/DQpJZiB0aGlzIHNlZW1zIE9LLCBJJ2xsIGVtaXQgYW5v dGhlciAtb3ZlcnZpZXcgbmV4dCB3ZWVrIHdpdGggdGhlc2UgZGVmaW5pdGlvbnMuDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICBvICBBIFdlYlJUQyBVc2VyIEFnZW50IChhbHNv IGNhbGxlZCBhbiBVQSBvciBicm93c2VyKSBpcyBzb21ldGhpbmcgdGhhdCBjb25mb3JtcyB0byBi b3RoIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGFuZCB0aGUgSmF2YXNjcmlwdCBBUEkgZGVm aW5lZCBhYm92ZS4NCg0KICAgIG8gIEEgV2ViUlRDIGRldmljZSBpcyBzb21ldGhpbmcgdGhhdCBj b25mb3JtcyB0byB0aGUgcHJvdG9jb2wNCiAgICAgICBzcGVjaWZpY2F0aW9uLCBidXQgZG9lcyBu b3QNCg0KY2xhaW0gdG8gaW1wbGVtZW50IHRoZSBKYXZhc2NyaXB0IEFQSS4NCg0KICAgIG8gIEEg V2ViUlRDIGVuZHBvaW50IGlzIGVpdGhlciBhIFdlYlJUQyBVQSBvciBhIFdlYlJUQyBkZXZpY2Uu DQoNCiAgICBvICBBIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IGlzIGFuIGVuZHBvaW50IHRo YXQgaXMgY2FwYWJsZSBvZiBzdWNjZXNzZnVsbHkgY29tbXVuaWNhdGluZyB3aXRoIGEgV2ViUlRD IGVuZHBvaW50LCBidXQgbWF5IGZhaWwgdG8gbWVldCBzb21lIHJlcXVpcmVtZW50IG9mIHRoZSBX ZWJSVEMgZW5kcG9pbnQuIFRoaXMgbWF5IGxpbWl0IHdoZXJlIGluIHRoZSBuZXR3b3JrIHN1Y2gg YW4gZW5kcG9pbnQgY2FuIGJlIGF0dGFjaGVkLCBvciBtYXkgbGltaXQgdGhlIHNlY3VyaXR5IGd1 YXJhbnRlZXMgdGhhdCBpdCBvZmZlcnMgdG8gb3RoZXJzLg0KDQogICAgbyAgQSBXZWJSVEMgZ2F0 ZXdheSBpcyBhIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IHRoYXQgbWVkaWF0ZXMgbWVkaWEg dHJhZmZpYyB0byBub24tV2ViUlRDIGVudGl0aWVzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQpGT1IgVFJBTlNQT1JUOg0KDQpBIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50 IGlzIGNhcGFibGUgb2YgaW5pdGl0YXRpbmcgb3IgYWNjZXB0aW5nIGEgc2Vzc2lvbiB3aXRoIGEg V2ViUlRDIGVuZHBvaW50LiBUaGUgZm9sbG93aW5nIHJlcXVpcmVtZW50cyBvbiBhIFdlYlJUQyBl bmRwb2ludCBhcmUgbm90IHJlcXVpcmVkIGZvciBzdWNoIHN1Y2Nlc3M6DQoNCi0gU3VwcG9ydCBm b3IgZnVsbCBJQ0UuIElmIHRoZSBlbmRwb2ludCBpcyBvbmx5IGV2ZXIgZ29pbmcgdG8gYmUgYXR0 YWNoZWQgdG8gdGhlIHB1YmxpYyBJbnRlcm5ldCwgaXQgZG9lcyBub3QgbmVlZCB0byBiZSBhYmxl IHRvIGZpeCBpdHMgb3duIGV4dGVybmFsIGFkZHJlc3M7DQoNCklDRS1MaXRlIGlzIGVub3VnaC4N Ci0gU3VwcG9ydCBmb3IgdGhlIGZ1bGwgc3VpdGUgb2YgTVRJIGNvZGVjcyBmb3IgYSBXZWJSVEMg ZW5kcG9pbnQuIEluIHBhcnRpY3VsYXIsIGF1ZGlvIGdhdGV3YXlzIHRoYXQgY29ubmVjdCB0byBu YXRpdmUgRy43MTEgbmV0d29ya3MgbWF5IGNob29zZSB0byBpbXBsZW1lbnQgRy43MTEgYW5kIG5v dCBpbXBsZW1lbnQgT3B1cy4NCi0gT2ZmZXJpbmcgQlVORExFIG9yIFJUQ1AtTVVYDQotIFVzaW5n IE1TSUQgaW4gaXRzIG9mZmVycyBvciBhbnN3ZXJzDQo8c2hvdWxkIGNvbmdlc3Rpb24gY3V0b2Zm IHJlcXVpcmVtZW50IGJlIGluIG9yIG91dD8+IDx0aGVyZSB3aWxsIGJlIG1vcmU+DQoNCk5vdGUg dGhhdCBzdXBwb3J0IGZvciBEVExTLCBJQ0UgYW5kIFRVUk4gQVJFIHJlcXVpcmVkIGZvciBhIFdl YlJUQy1jb21wYXRpYmxlIGVuZHBvaW50LCBhbmQgaWYgUlRQIGlzIHVzZWQgYXQgYWxsLCBEVExT LVNSVFAgTVVTVCBiZSB1c2VkLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K LS0NClNlbnQgZnJvbSBteSBBbmRyb2lkIGRldmljZSB3aXRoIEstOSBNYWlsLiBQbGVhc2UgZXhj dXNlIG15IGJyZXZpdHkuDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D465985ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jmd0Ozwvc3Bhbj5ZdXAsIHR1cm4gaXMgd3JvbmcuIEFuZCBpY2UgbmVlZHMgdG8gYmUg bWFkZSBtb3JlIHByZWNpc2UgLSBwb2ludCBpcywNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mZ3Q7PC9zcGFuPndpdGhvdXQgYW55IGljZSwgdGhpbmdzIHdpbGwgbm90IHdvcmsgYXQgYWxs LjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ3JlZS4gQnV0LCBJIHRoaW5rIHRoZSBi dWxsZXQgdGFsa2luZyBhYm91dCDigJxJQ0UgbGl0ZeKAnSBpcyBlbm91Z2guPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5EVExTOiBB IHdlYnJ0YyBlbmRwb2ludCBlaXRoZXIgdXNlcyBkYXRhIGNoYW5uZWxzLCB3aGljaCByZXF1aXJl IGR0bHMsDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5vciBydHAsIHdo dWNoIHJlcXVpcmVzIERUTFMtc3J0cCwgd2hpY2ggcmVxdWlyZXMgZHRscywgc28gSSBmaWd1cmVk IGl0DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj53YXMgc2FmZSB0byBz YXkgdGhhdCBkdGxzIHdhcyByZXF1aXJlZC48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZXhwbGljaXRseSBpbmRpY2F0ZSB0aGUgdXNh Z2VzIGZvciB3aGljaCBEVExTIG5lZWRzIHRvIGJlIHN1cHBvcnRlZCwgaWUgRFRMUy1TUlRQIGZv ciBSVFAgYW5kIGFzDQogZGVmaW5lZCBmb3IgZGF0YSBjaGFubmVscy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZWNhdXNlLCBEVExT IGNhbiBiZSB1c2VkIGZvciBtYW55IGRpZmZlcmVudCBwdXJwb3NlcywgaW4gZGlmZmVyZW50IHdh eXMsIHNvIGp1c3Qgc2F5aW5nIOKAnHN1cHBvcnQgRFRMU+KAnSBpcyB1bmNsZWFyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RGVuIDMuIG9rdG9iZXIgMjAxNCAxNDowMToyMCBDRVNULCBza3Jl diBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHByZT5IaSw8YnI+PGJyPkZpcnN0LCBJIHBlcnNv bmFsbHkgc2VlIG5vIG5lZWQgZm9yIGFsbCB0aGVzZSBkZWZpbml0aW9ucy48YnI+PGJyPkkgdGhp bmsgaXQgd291bGQgYmUgZW5vdWdoIHRvIGhhdmU6PGJyPjxicj4tIFdlYlJUQyBlbmRwb2ludCAo ZS5nLiBhIGJyb3dzZXIpPGJyPi0gV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQgKGUuZy4gYSBn YXRld2F5KTxicj48YnI+SWYgcGVvcGxlIHJlYWxseSB0aGluayB3ZSBuZWVkIG1vcmUsIEkgd29u J3QgYXJndWUgYWdhaW5zdC4gSSBqdXN0IHRoaW5rIGl0IGJlY29tZXMgdmVyeSBtZXNzeSwgYW5k IHBlb3BsZSBXSUxMIGVuZCB1cCB1c2luZyB0aGUgd3JvbmcgdGVybWlub2xvZ3kgOik8YnI+PGJy Pjxicj5TZWNvbmQsIHlvdSBzYXk6PGJyPjxicj4gJnF1b3Q7Tm90ZSB0aGF0IHN1cHBvcnQgZm9y IERUTFMsIElDRSBhbmQgVFVSTiBBUkUgcmVxdWlyZWQgZm9yIGEgV2ViUlRDLWNvbXBhdGlibGUg ZW5kcG9pbnQsIGFuZCBpZiBSVFAgaXMgdXNlZCBhdCBhbGwsIERUTFMtU1JUUCBNVVNUIGJlIHVz ZWQuJnF1b3Q7PGJyPjxicj5Zb3UgYWxyZWFkeSBpbiB0aGUgYnVsbGV0IGxpc3Qgc2FpZCBzdXBw b3J0IG9mIElDRSBsaXRlLCBzbyB0aGUgdGV4dCBpcyBjb25mbGljdGluZy4gPGJyPjxicj5JIGFt IG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgJnF1b3Q7c3VwcG9ydCBmb3IgVFVSTiZxdW90Oy4g QW4gSUNFIGxpdGUgZW5kcG9pbnQgd2lsbCBub3QgY3JlYXRlIFRVUk4gY2FuZGlkYXRlcyBldGMu IE9mIGNvdXJzZSwgaXQgbWF5IHJlY2VpdmUgbWVkaWEgdmlhIGEgVFVSTiBzZXJ2ZXIuPGJyPjxi cj5XaGF0IGRvIHlvdSBtZWFuIGJ5ICZxdW90O3N1cHBvcnQgZm9yIERUTFMmcXVvdDs/IEkgdGhp bmsgeW91IG5lZWQgdG8gYmUgYSBsaXR0bGUgbW9yZSBzcGVjaWZpYyAobGF0ZXIgeW91IGRvIG1l bnRpb24gRFRMUy1TUlRQIGluIGNhc2Ugb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SVFApLjxi cj48YnI+UmVnYXJkcyw8YnI+PGJyPkNocmlzdGVyPGJyPjxicj48YnI+PGJyPjxicj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiBydGN3ZWIgWzxhIGhyZWY9Im1haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPl0g T24gQmVoYWxmIE9mIEhhcmFsZCBBbHZlc3RyYW5kPGJyPlNlbnQ6IDMuIGxva2FrdXV0YSAyMDE0 IDEwOjQ0PGJyPlRvOiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0 Zi5vcmc8L2E+PGJyPlN1YmplY3Q6IFtydGN3ZWJdIERlZmluaXRpb25zIG9mIFdlYlJUQyBlbnRp dGllczxicj48YnI+QWZ0ZXIgYWxsIHRoZSBmZWVkYmFjaywgSSd2ZSB0YWtlbiBhbm90aGVyIHdo YWNrIGF0IHRoaXMuPGJyPjxicj5JdCBzZWVtcyB0aGF0IHRoZSB0ZXJtICZxdW90O1dlYlJUQyBl bmRwb2ludCZxdW90OyBpcyBhbHJlYWR5IHVzZWQgd2lkZWx5IGVub3VnaCB0aGF0IGl0J3Mgd29y dGggY29udGludWluZyB0byB1c2UgaXQuIFNvIEkgZW5kZWQgdXAgd2l0aCB0aGUgZm9sbG93aW5n IHN1Z2dlc3RlZCB0ZXh0IGZvciAtb3ZlcnZpZXcncyBkZWZpbml0aW9ucy48YnI+PGJyPkNvbW1l bnRzPzxicj5JZiB0aGlzIHNlZW1zIE9LLCBJJ2xsIGVtaXQgYW5vdGhlciAtb3ZlcnZpZXcgbmV4 dCB3ZWVrIHdpdGggdGhlc2UgZGVmaW5pdGlvbnMuPGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQSBXZWJSVEMgVXNlciBB Z2VudCAoYWxzbyBjYWxsZWQgYW4gVUEgb3IgYnJvd3NlcikgaXMgc29tZXRoaW5nIHRoYXQgY29u Zm9ybXMgdG8gYm90aCB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBhbmQgdGhlIEphdmFzY3Jp cHQgQVBJIGRlZmluZWQgYWJvdmUuPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBB IFdlYlJUQyBkZXZpY2UgaXMgc29tZXRoaW5nIHRoYXQgY29uZm9ybXMgdG8gdGhlIHByb3RvY29s PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpY2F0aW9uLCBi dXQgZG9lcyBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jbGFpbSB0byBpbXBsZW1lbnQgdGhl IEphdmFzY3JpcHQgQVBJLjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQSBXZWJS VEMgZW5kcG9pbnQgaXMgZWl0aGVyIGEgV2ViUlRDIFVBIG9yIGEgV2ViUlRDIGRldmljZS48YnI+ PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEEgV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9p bnQgaXMgYW4gZW5kcG9pbnQgdGhhdCBpcyBjYXBhYmxlIG9mIHN1Y2Nlc3NmdWxseSBjb21tdW5p Y2F0aW5nIHdpdGggYSBXZWJSVEMgZW5kcG9pbnQsIGJ1dCBtYXkgZmFpbCB0byBtZWV0IHNvbWUg cmVxdWlyZW1lbnQgb2YgdGhlIFdlYlJUQyBlbmRwb2ludC4gVGhpcyBtYXkgbGltaXQgd2hlcmUg aW4gdGhlIG5ldHdvcmsgc3VjaCBhbiBlbmRwb2ludCBjYW4gYmUgYXR0YWNoZWQsIG9yIG1heSBs aW1pdCB0aGUgc2VjdXJpdHkgZ3VhcmFudGVlcyB0aGF0IGl0IG9mZmVycyB0byBvdGhlcnMuPGJy Pjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBIFdlYlJUQyBnYXRld2F5IGlzIGEgV2Vi UlRDLWNvbXBhdGlibGUgZW5kcG9pbnQgdGhhdCBtZWRpYXRlcyBtZWRpYSB0cmFmZmljIHRvIG5v bi1XZWJSVEMgZW50aXRpZXMuPGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj48YnI+Rk9SIFRSQU5TUE9SVDo8YnI+PGJyPkEgV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQg aXMgY2FwYWJsZSBvZiBpbml0aXRhdGluZyBvciBhY2NlcHRpbmcgYSBzZXNzaW9uIHdpdGggYSBX ZWJSVEMgZW5kcG9pbnQuIFRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnRzIG9uIGEgV2ViUlRDIGVu ZHBvaW50IGFyZSBub3QgcmVxdWlyZWQgZm9yIHN1Y2ggc3VjY2Vzczo8YnI+PGJyPi0gU3VwcG9y dCBmb3IgZnVsbCBJQ0UuIElmIHRoZSBlbmRwb2ludCBpcyBvbmx5IGV2ZXIgZ29pbmcgdG8gYmUg YXR0YWNoZWQgdG8gdGhlIHB1YmxpYyBJbnRlcm5ldCwgaXQgZG9lcyBub3QgbmVlZCB0byBiZSBh YmxlIHRvIGZpeCBpdHMgb3duIGV4dGVybmFsIGFkZHJlc3M7PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JQ0UtTGl0ZSBpcyBlbm91Z2guPGJyPi0g U3VwcG9ydCBmb3IgdGhlIGZ1bGwgc3VpdGUgb2YgTVRJIGNvZGVjcyBmb3IgYSBXZWJSVEMgZW5k cG9pbnQuIEluIHBhcnRpY3VsYXIsIGF1ZGlvIGdhdGV3YXlzIHRoYXQgY29ubmVjdCB0byBuYXRp dmUgRy43MTEgbmV0d29ya3MgbWF5IGNob29zZSB0byBpbXBsZW1lbnQgRy43MTEgYW5kIG5vdCBp bXBsZW1lbnQgT3B1cy48YnI+LSBPZmZlcmluZyBCVU5ETEUgb3IgUlRDUC1NVVg8YnI+LSBVc2lu ZyBNU0lEIGluIGl0cyBvZmZlcnMgb3IgYW5zd2Vyczxicj4mbHQ7c2hvdWxkIGNvbmdlc3Rpb24g Y3V0b2ZmIHJlcXVpcmVtZW50IGJlIGluIG9yIG91dD8mZ3Q7ICZsdDt0aGVyZSB3aWxsIGJlIG1v cmUmZ3Q7PGJyPjxicj5Ob3RlIHRoYXQgc3VwcG9ydCBmb3IgRFRMUywgSUNFIGFuZCBUVVJOIEFS RSByZXF1aXJlZCBmb3IgYSBXZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludCwgYW5kIGlmIFJUUCBp cyB1c2VkIGF0IGFsbCwgRFRMUy1TUlRQIE1VU1QgYmUgdXNlZC48YnI+PGJyPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PGhyIHNpemU9IjMiIHdpZHRo PSIxMDAlIiBhbGlnbj0iY2VudGVyIj48L3ByZT4NCjxwcmU+PGJyPnJ0Y3dlYiBtYWlsaW5nIGxp c3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9h Pjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl YiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48 L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KLS0gPGJyPg0KU2VudCBmcm9tIG15IEFuZHJvaWQgZGV2aWNlIHdpdGggSy05IE1haWwu IFBsZWFzZSBleGN1c2UgbXkgYnJldml0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D465985ESESSMB209erics_-- From nobody Fri Oct 3 10:36:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A220F1A879E for ; Fri, 3 Oct 2014 10:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utMpTLKUEFJ1 for ; Fri, 3 Oct 2014 10:36:18 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E561A8795 for ; Fri, 3 Oct 2014 10:36:17 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-ff-542ede8f3576 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.8A.21334.F8EDE245; Fri, 3 Oct 2014 19:36:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Fri, 3 Oct 2014 19:36:15 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Definitions of WebRTC entities Thread-Index: AQHP3t3ehH0V0UJNhEaGpnZRIRprGZweQ+vQ///tNQCAAG62UIAAAtpw Date: Fri, 3 Oct 2014 17:36:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW7/Pb0Qg9b/8hbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDL+Tf7LWHBLt+LKjl8sDYxHdLoYOTkkBEwk Vu5oZYWwxSQu3FvP1sXIxSEkcJRR4l1zFwuEs5hR4t+hL8xdjBwcbAIWEt3/tEEaRASCJXqf v2cEsYWBBu2ct4kRIm4q0TXrPpTtJnHx6ndmEJtFQEXiUds2JhCbV8BXYsqdbYwQ818zSsw4 sYcdZD6ngJ/EojXyIDWMQAd9P7UGrJ5ZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B/UA0oSi25/ ZgIZwyygKbF+lz5Eq6LElO6H7BBrBSVOznzCMoFRdBaSqbMQOmYh6ZiFpGMBI8sqRtHi1OLi 3HQjY73Uoszk4uL8PL281JJNjMAYObjlt+4OxtWvHQ8xCnAwKvHwKjDrhQixJpYVV+YeYpTm YFES5110bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbAZp2o2ocTipN/xk1foiulcPDa 8l3dAYe8t7D89MktPnvFvDg5+0qYzuetYRE5C1hZ5C/1XV1+aZVwqgTn2nT/v8rOYnvcU1P/ f3IxUpTv+M34Xf/A6uyrkxT6dv5Kenn/pJTUsj9959dtb1A6dcjgZ4e1ZvvRf/4nN/VXlCxP dJFRdXrWq6XEUpyRaKjFXFScCABjCERpcgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9l2ev35DQl6ggwniSpek-UoWoUI Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Oct 2014 17:36:19 -0000 SGksDQoNCj4+RFRMUzogQSB3ZWJydGMgZW5kcG9pbnQgZWl0aGVyIHVzZXMgZGF0YSBjaGFubmVs cywgd2hpY2ggcmVxdWlyZSBkdGxzLCBvciBydHAsIHdodWNoIHJlcXVpcmVzIERUTFMtc3J0cCwg d2hpY2ggcmVxdWlyZXMgZHRscywgc28gSSBmaWd1cmVkIGl0IA0KPj53YXMgc2FmZSB0byBzYXkg dGhhdCBkdGxzIHdhcyByZXF1aXJlZC4NCj4NCj5JIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0 byBleHBsaWNpdGx5IGluZGljYXRlIHRoZSB1c2FnZXMgZm9yIHdoaWNoIERUTFMgbmVlZHMgdG8g YmUgc3VwcG9ydGVkLCBpZSBEVExTLVNSVFAgZm9yIFJUUCBhbmQgYXMgZGVmaW5lZCBmb3IgZGF0 YSBjaGFubmVscy4NCj5CZWNhdXNlLCBEVExTIGNhbiBiZSB1c2VkIGZvciBtYW55IGRpZmZlcmVu dCBwdXJwb3NlcywgaW4gZGlmZmVyZW50IHdheXMsIHNvIGp1c3Qgc2F5aW5nIOKAnHN1cHBvcnQg RFRMU+KAnSBpcyB1bmNsZWFyLg0KDQpJbiBhZGRpdGlvbiwgaXQgaXMgcHJvYmFibHkgdXNlZnVs IHRvIGluZGljYXRlIHRoYXQgYW4gY29tcGF0aWJsZSBlbmRwb2ludCBtYXkgbm90IG5lY2Vzc2Fy aWx5IHRlcm1pbmF0ZSBhbGwgRFRMUyB1c2FnZXMuIEZvciBleGFtcGxlLCBhIGdhdGV3YXkgbWln aHQgc2ltcGx5IHBhc3MgdGhyb3VnaCB0aGUgZGF0YSBjaGFubmVsLCBhbmQvb3IgdGhlIFNSVFAg dHJhZmZpYy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCkRlbiAzLiBva3Rv YmVyIDIwMTQgMTQ6MDE6MjAgQ0VTVCwgc2tyZXYgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT46DQpIaSwNCg0KRmlyc3QsIEkgcGVyc29uYWxseSBzZWUg bm8gbmVlZCBmb3IgYWxsIHRoZXNlIGRlZmluaXRpb25zLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJl IGVub3VnaCB0byBoYXZlOg0KDQotIFdlYlJUQyBlbmRwb2ludCAoZS5nLiBhIGJyb3dzZXIpDQot IFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IChlLmcuIGEgZ2F0ZXdheSkNCg0KSWYgcGVvcGxl IHJlYWxseSB0aGluayB3ZSBuZWVkIG1vcmUsIEkgd29uJ3QgYXJndWUgYWdhaW5zdC4gSSBqdXN0 IHRoaW5rIGl0IGJlY29tZXMgdmVyeSBtZXNzeSwgYW5kIHBlb3BsZSBXSUxMIGVuZCB1cCB1c2lu ZyB0aGUgd3JvbmcgdGVybWlub2xvZ3kgOikNCg0KDQpTZWNvbmQsIHlvdSBzYXk6DQoNCiAiTm90 ZSB0aGF0IHN1cHBvcnQgZm9yIERUTFMsIElDRSBhbmQgVFVSTiBBUkUgcmVxdWlyZWQgZm9yIGEg V2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQsIGFuZCBpZiBSVFAgaXMgdXNlZCBhdCBhbGwsIERU TFMtU1JUUCBNVVNUIGJlIHVzZWQuIg0KDQpZb3UgYWxyZWFkeSBpbiB0aGUgYnVsbGV0IGxpc3Qg c2FpZCBzdXBwb3J0IG9mIElDRSBsaXRlLCBzbyB0aGUgdGV4dCBpcyBjb25mbGljdGluZy4gDQoN CkkgYW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSAic3VwcG9ydCBmb3IgVFVSTiIuIEFuIElD RSBsaXRlIGVuZHBvaW50IHdpbGwgbm90IGNyZWF0ZSBUVVJOIGNhbmRpZGF0ZXMgZXRjLiBPZiBj b3Vyc2UsIGl0IG1heSByZWNlaXZlIG1lZGlhIHZpYSBhIFRVUk4gc2VydmVyLg0KDQpXaGF0IGRv IHlvdSBtZWFuIGJ5ICJzdXBwb3J0IGZvciBEVExTIj8gSSB0aGluayB5b3UgbmVlZCB0byBiZSBh IGxpdHRsZSBtb3JlIHNwZWNpZmljIChsYXRlciB5b3UgZG8gbWVudGlvbiBEVExTLVNSVFAgaW4g Y2FzZSBvZg0KUlRQKS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSGFyYWxkIEFsdmVzdHJhbmQNClNlbnQ6IDMuIGxva2FrdXV0 YSAyMDE0IDEwOjQ0DQpUbzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBbcnRjd2ViXSBEZWZp bml0aW9ucyBvZiBXZWJSVEMgZW50aXRpZXMNCg0KQWZ0ZXIgYWxsIHRoZSBmZWVkYmFjaywgSSd2 ZSB0YWtlbiBhbm90aGVyIHdoYWNrIGF0IHRoaXMuDQoNCkl0IHNlZW1zIHRoYXQgdGhlIHRlcm0g IldlYlJUQyBlbmRwb2ludCIgaXMgYWxyZWFkeSB1c2VkIHdpZGVseSBlbm91Z2ggdGhhdCBpdCdz IHdvcnRoIGNvbnRpbnVpbmcgdG8gdXNlIGl0LiBTbyBJIGVuZGVkIHVwIHdpdGggdGhlIGZvbGxv d2luZyBzdWdnZXN0ZWQgdGV4dCBmb3IgLW92ZXJ2aWV3J3MgZGVmaW5pdGlvbnMuDQoNCkNvbW1l bnRzPw0KSWYgdGhpcyBzZWVtcyBPSywgSSdsbCBlbWl0IGFub3RoZXIgLW92ZXJ2aWV3IG5leHQg d2VlayB3aXRoIHRoZXNlIGRlZmluaXRpb25zLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQrCoMKgwqAgb8KgIEEgV2ViUlRDIFVzZXIgQWdlbnQgKGFsc28gY2FsbGVkIGFuIFVBIG9y IGJyb3dzZXIpIGlzIHNvbWV0aGluZyB0aGF0IGNvbmZvcm1zIHRvIGJvdGggdGhlIHByb3RvY29s IHNwZWNpZmljYXRpb24gYW5kIHRoZSBKYXZhc2NyaXB0IEFQSSBkZWZpbmVkIGFib3ZlLg0KDQrC oMKgwqAgb8KgIEEgV2ViUlRDIGRldmljZSBpcyBzb21ldGhpbmcgdGhhdCBjb25mb3JtcyB0byB0 aGUgcHJvdG9jb2wNCsKgwqDCoMKgwqDCoCBzcGVjaWZpY2F0aW9uLCBidXQgZG9lcyBub3QNCmNs YWltIHRvIGltcGxlbWVudCB0aGUgSmF2YXNjcmlwdCBBUEkuDQoNCsKgwqDCoCBvwqAgQSBXZWJS VEMgZW5kcG9pbnQgaXMgZWl0aGVyIGEgV2ViUlRDIFVBIG9yIGEgV2ViUlRDIGRldmljZS4NCg0K wqDCoMKgIG/CoCBBIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IGlzIGFuIGVuZHBvaW50IHRo YXQgaXMgY2FwYWJsZSBvZiBzdWNjZXNzZnVsbHkgY29tbXVuaWNhdGluZyB3aXRoIGEgV2ViUlRD IGVuZHBvaW50LCBidXQgbWF5IGZhaWwgdG8gbWVldCBzb21lIHJlcXVpcmVtZW50IG9mIHRoZSBX ZWJSVEMgZW5kcG9pbnQuIFRoaXMgbWF5IGxpbWl0IHdoZXJlIGluIHRoZSBuZXR3b3JrIHN1Y2gg YW4gZW5kcG9pbnQgY2FuIGJlIGF0dGFjaGVkLCBvciBtYXkgbGltaXQgdGhlIHNlY3VyaXR5IGd1 YXJhbnRlZXMgdGhhdCBpdCBvZmZlcnMgdG8gb3RoZXJzLg0KDQrCoMKgwqAgb8KgIEEgV2ViUlRD IGdhdGV3YXkgaXMgYSBXZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludCB0aGF0IG1lZGlhdGVzIG1l ZGlhIHRyYWZmaWMgdG8gbm9uLVdlYlJUQyBlbnRpdGllcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KRk9SIFRSQU5TUE9SVDoNCg0KQSBXZWJSVEMtY29tcGF0aWJsZSBlbmRw b2ludCBpcyBjYXBhYmxlIG9mIGluaXRpdGF0aW5nIG9yIGFjY2VwdGluZyBhIHNlc3Npb24gd2l0 aCBhIFdlYlJUQyBlbmRwb2ludC4gVGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHMgb24gYSBXZWJS VEMgZW5kcG9pbnQgYXJlIG5vdCByZXF1aXJlZCBmb3Igc3VjaCBzdWNjZXNzOg0KDQotIFN1cHBv cnQgZm9yIGZ1bGwgSUNFLiBJZiB0aGUgZW5kcG9pbnQgaXMgb25seSBldmVyIGdvaW5nIHRvIGJl IGF0dGFjaGVkIHRvIHRoZSBwdWJsaWMgSW50ZXJuZXQsIGl0IGRvZXMgbm90IG5lZWQgdG8gYmUg YWJsZSB0byBmaXggaXRzIG93biBleHRlcm5hbCBhZGRyZXNzOw0KSUNFLUxpdGUgaXMgZW5vdWdo Lg0KLSBTdXBwb3J0IGZvciB0aGUgZnVsbCBzdWl0ZSBvZiBNVEkgY29kZWNzIGZvciBhIFdlYlJU QyBlbmRwb2ludC4gSW4gcGFydGljdWxhciwgYXVkaW8gZ2F0ZXdheXMgdGhhdCBjb25uZWN0IHRv IG5hdGl2ZSBHLjcxMSBuZXR3b3JrcyBtYXkgY2hvb3NlIHRvIGltcGxlbWVudCBHLjcxMSBhbmQg bm90IGltcGxlbWVudCBPcHVzLg0KLSBPZmZlcmluZyBCVU5ETEUgb3IgUlRDUC1NVVgNCi0gVXNp bmcgTVNJRCBpbiBpdHMgb2ZmZXJzIG9yIGFuc3dlcnMNCjxzaG91bGQgY29uZ2VzdGlvbiBjdXRv ZmYgcmVxdWlyZW1lbnQgYmUgaW4gb3Igb3V0Pz4gPHRoZXJlIHdpbGwgYmUgbW9yZT4NCg0KTm90 ZSB0aGF0IHN1cHBvcnQgZm9yIERUTFMsIElDRSBhbmQgVFVSTiBBUkUgcmVxdWlyZWQgZm9yIGEg V2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQsIGFuZCBpZiBSVFAgaXMgdXNlZCBhdCBhbGwsIERU TFMtU1JUUCBNVVNUIGJlIHVzZWQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KLS0gDQpTZW50IGZyb20gbXkg QW5kcm9pZCBkZXZpY2Ugd2l0aCBLLTkgTWFpbC4gUGxlYXNlIGV4Y3VzZSBteSBicmV2aXR5Lg0K From nobody Fri Oct 3 13:41:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9879A1A7014 for ; Fri, 3 Oct 2014 13:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRL90EGXTmrh for ; Fri, 3 Oct 2014 13:41:24 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A238A1A6FDC for ; Fri, 3 Oct 2014 13:41:24 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 20so618612yks.15 for ; Fri, 03 Oct 2014 13:41:24 -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=fkjysYvqQmE4A2Ig6wTEY0055A+WH2pDN5oVFv6AaoY=; b=Gj+Utj/oaJyrI6Qt4WWt3Hg8rH8jv1CGbYSQpGB52Jgwj0LYPzdjdswAGupAOWCH+5 et3ECmRfqD6F5UusDVre05yXE1611gmWEZQ4KXeJ2/jp3EiwryMONYL1X1Fr8Pj6g7Mj x1EeEH5mXhJX+gpVr0GB1ilb8Hmnyw6YS++bHDBICJIBqu0D8KabnJAMaXfoyN9H0SFp wbWKou3oux5Jx40JWUzrNk7J49JENe2MmN4p97LWWKv7jl2FB4tA0j8cIzOqh0nhfw0t Q+tBDc3UVVDn4EaSyI8uFYroevkkudEcefZiB2bHr4vdl1CzP9Dt8HY3bEmv5eVNk3T0 y30g== MIME-Version: 1.0 X-Received: by 10.236.154.134 with SMTP id h6mr11471674yhk.70.1412368883806; Fri, 03 Oct 2014 13:41:23 -0700 (PDT) Received: by 10.170.219.194 with HTTP; Fri, 3 Oct 2014 13:41:23 -0700 (PDT) Received: by 10.170.219.194 with HTTP; Fri, 3 Oct 2014 13:41:23 -0700 (PDT) In-Reply-To: <542E53D2.5040500@alvestrand.no> References: <542E53D2.5040500@alvestrand.no> Date: Sat, 4 Oct 2014 06:41:23 +1000 Message-ID: From: Silvia Pfeiffer To: Harald Alvestrand Content-Type: multipart/alternative; boundary=20cf303bfada9c779c05048ac1aa Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lIPpMlFjUv5IsWVnTdLCtzgednE Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Oct 2014 20:41:26 -0000 --20cf303bfada9c779c05048ac1aa Content-Type: text/plain; charset=UTF-8 These are good! On 3 Oct 2014 17:44, "Harald Alvestrand" wrote: > > After all the feedback, I've taken another whack at this. > > It seems that the term "WebRTC endpoint" is already used widely enough that it's worth continuing to use it. So I ended up with the following suggested text for -overview's definitions. > > Comments? > If this seems OK, I'll emit another -overview next week with these definitions. > > -------------------------- > > o A WebRTC User Agent (also called an UA or browser) is something that conforms to both the protocol specification and the Javascript API defined above. > > o A WebRTC device is something that conforms to the protocol > specification, but does not claim to implement the Javascript API. > > o A WebRTC endpoint is either a WebRTC UA or a WebRTC device. Since a webrtc UA is a superset of a webrtc device, webrtc endpoint and webrtc device end up meaning the same, don't they? > o A WebRTC-compatible endpoint is an endpoint that is capable of successfully communicating with a WebRTC endpoint, but may fail to meet some requirement of the WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others. > > o A WebRTC gateway is a WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities. > > ----------------------------- > > FOR TRANSPORT: > > A WebRTC-compatible endpoint is capable of inititating or accepting a session with a WebRTC endpoint. The following requirements on a WebRTC endpoint are not required for such success: > > - Support for full ICE. If the endpoint is only ever going to be attached to the public Internet, it does not need to be able to fix its own external address; ICE-Lite is enough. > - Support for the full suite of MTI codecs for a WebRTC endpoint. In particular, audio gateways that connect to native G.711 networks may choose to implement G.711 and not implement Opus. > - Offering BUNDLE or RTCP-MUX > - Using MSID in its offers or answers > > > > Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used. > > Is your intent to specify which parts of the protocol are not required to be supported by webrtc-compatible endpoints in a rfc? I think it would be useful... Silvia. _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --20cf303bfada9c779c05048ac1aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

These are good!

On 3 Oct 2014 17:44, "Harald Alvestrand" <harald@alvestrand.no> wrote:
>
> After all the feedback, I've taken another whack at this.
>
> It seems that the term "WebRTC endpoint" is already used wid= ely enough that it's worth continuing to use it. So I ended up with the= following suggested text for -overview's definitions.
>
> Comments?
> If this seems OK, I'll emit another -overview next week with these= definitions.
>
> --------------------------
>
> =C2=A0 =C2=A0o=C2=A0 A WebRTC User Agent (also called an UA or browser= ) is something that conforms to both the protocol specification and the Jav= ascript API defined above.
>
> =C2=A0 =C2=A0o=C2=A0 A WebRTC device is something that conforms to the= protocol
> =C2=A0 =C2=A0 =C2=A0 specification, but does not claim to implement th= e Javascript API.
>
> =C2=A0 =C2=A0o=C2=A0 A WebRTC endpoint is either a WebRTC UA or a WebR= TC device.

Since a webrtc UA is a superset of a webrtc device, webrtc e= ndpoint and webrtc device end up meaning the same, don't they?

> =C2=A0 =C2=A0o=C2=A0 A WebRTC-compatible endpoint is an= endpoint that is capable of successfully communicating with a WebRTC endpo= int, but may fail to meet some requirement of the WebRTC endpoint. This may= limit where in the network such an endpoint can be attached, or may limit = the security guarantees that it offers to others.
>
> =C2=A0 =C2=A0o=C2=A0 A WebRTC gateway is a WebRTC-compatible endpoint = that mediates media traffic to non-WebRTC entities.
>
> -----------------------------
>
> FOR TRANSPORT:
>
> A WebRTC-compatible endpoint is capable of inititating or accepting a = session with a WebRTC endpoint. The following requirements on a WebRTC endp= oint are not required for such success:
>
> - Support for full ICE. If the endpoint is only ever going to be attac= hed to the public Internet, it does not need to be able to fix its own exte= rnal address; ICE-Lite is enough.
> - Support for the full suite of MTI codecs for a WebRTC endpoint. In p= articular, audio gateways that connect to native G.711 networks may choose = to implement G.711 and not implement Opus.
> - Offering BUNDLE or RTCP-MUX
> - Using MSID in its offers or answers
> <should congestion cutoff requirement be in or out?>
> <there will be more>
>
> Note that support for DTLS, ICE and TURN ARE required for a WebRTC-com= patible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used.
>
>

Is your intent to specify which parts of the protocol are no= t required to be supported by webrtc-compatible endpoints in a rfc? I think= it would be useful...

Silvia.
_______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--20cf303bfada9c779c05048ac1aa-- From nobody Mon Oct 6 02:55:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CF11A1B87 for ; Mon, 6 Oct 2014 02:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRLZfUdlYMGS for ; Mon, 6 Oct 2014 02:55:47 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id A37171A1B8C for ; Mon, 6 Oct 2014 02:55:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6EBE57C3E96; Mon, 6 Oct 2014 11:55:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8lduy8cOl3n; Mon, 6 Oct 2014 11:55:43 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:554b:d51b:d65b:50a8] (unknown [IPv6:2001:470:de0a:27:554b:d51b:d65b:50a8]) by mork.alvestrand.no (Postfix) with ESMTPSA id 98B8A7C3CFA; Mon, 6 Oct 2014 11:55:43 +0200 (CEST) Message-ID: <5432671F.7020607@alvestrand.no> Date: Mon, 06 Oct 2014 11:55:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Silvia Pfeiffer References: <542E53D2.5040500@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020402050505090300050407" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DPY4lNy6TcwejRsRJQofZsewxa0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 06 Oct 2014 09:55:50 -0000 This is a multi-part message in MIME format. --------------020402050505090300050407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Den 03. okt. 2014 22:41, skrev Silvia Pfeiffer: > > These are good! > > On 3 Oct 2014 17:44, "Harald Alvestrand" > wrote: > > > > After all the feedback, I've taken another whack at this. > > > > It seems that the term "WebRTC endpoint" is already used widely > enough that it's worth continuing to use it. So I ended up with the > following suggested text for -overview's definitions. > > > > Comments? > > If this seems OK, I'll emit another -overview next week with these > definitions. > > > > -------------------------- > > > > o A WebRTC User Agent (also called an UA or browser) is > something that conforms to both the protocol specification and the > Javascript API defined above. > > > > o A WebRTC device is something that conforms to the protocol > > specification, but does not claim to implement the Javascript API. > > > > o A WebRTC endpoint is either a WebRTC UA or a WebRTC device. > > Since a webrtc UA is a superset of a webrtc device, webrtc endpoint > and webrtc device end up meaning the same, don't they? > > > o A WebRTC-compatible endpoint is an endpoint that is capable of > successfully communicating with a WebRTC endpoint, but may fail to > meet some requirement of the WebRTC endpoint. This may limit where in > the network such an endpoint can be attached, or may limit the > security guarantees that it offers to others. > > > > o A WebRTC gateway is a WebRTC-compatible endpoint that mediates > media traffic to non-WebRTC entities. > > > > ----------------------------- > > > > FOR TRANSPORT: > > > > A WebRTC-compatible endpoint is capable of inititating or accepting > a session with a WebRTC endpoint. The following requirements on a > WebRTC endpoint are not required for such success: > > > > - Support for full ICE. If the endpoint is only ever going to be > attached to the public Internet, it does not need to be able to fix > its own external address; ICE-Lite is enough. > > - Support for the full suite of MTI codecs for a WebRTC endpoint. In > particular, audio gateways that connect to native G.711 networks may > choose to implement G.711 and not implement Opus. > > - Offering BUNDLE or RTCP-MUX > > - Using MSID in its offers or answers > > > > > > > > Note that support for DTLS, ICE and TURN ARE required for a > WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST > be used. > > > > > > Is your intent to specify which parts of the protocol are not required > to be supported by webrtc-compatible endpoints in a rfc? I think it > would be useful... > Yes, -transport is intended to be published as an RFC. So is draft-alvestrand-rtcweb-gateways (if the group accepts it). > Silvia. > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > --------------020402050505090300050407 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Den 03. okt. 2014 22:41, skrev Silvia Pfeiffer:

These are good!

On 3 Oct 2014 17:44, "Harald Alvestrand" <harald@alvestrand.no> wrote:
>
> After all the feedback, I've taken another whack at this.
>
> It seems that the term "WebRTC endpoint" is already used widely enough that it's worth continuing to use it. So I ended up with the following suggested text for -overview's definitions.
>
> Comments?
> If this seems OK, I'll emit another -overview next week with these definitions.
>
> --------------------------
>
>    o  A WebRTC User Agent (also called an UA or browser) is something that conforms to both the protocol specification and the Javascript API defined above.
>
>    o  A WebRTC device is something that conforms to the protocol
>       specification, but does not claim to implement the Javascript API.
>
>    o  A WebRTC endpoint is either a WebRTC UA or a WebRTC device.

Since a webrtc UA is a superset of a webrtc device, webrtc endpoint and webrtc device end up meaning the same, don't they?

>    o  A WebRTC-compatible endpoint is an endpoint that is capable of successfully communicating with a WebRTC endpoint, but may fail to meet some requirement of the WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others.
>
>    o  A WebRTC gateway is a WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities.
>
> -----------------------------
>
> FOR TRANSPORT:
>
> A WebRTC-compatible endpoint is capable of inititating or accepting a session with a WebRTC endpoint. The following requirements on a WebRTC endpoint are not required for such success:
>
> - Support for full ICE. If the endpoint is only ever going to be attached to the public Internet, it does not need to be able to fix its own external address; ICE-Lite is enough.
> - Support for the full suite of MTI codecs for a WebRTC endpoint. In particular, audio gateways that connect to native G.711 networks may choose to implement G.711 and not implement Opus.
> - Offering BUNDLE or RTCP-MUX
> - Using MSID in its offers or answers
> <should congestion cutoff requirement be in or out?>
> <there will be more>
>
> Note that support for DTLS, ICE and TURN ARE required for a WebRTC-compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used.
>
>

Is your intent to specify which parts of the protocol are not required to be supported by webrtc-compatible endpoints in a rfc? I think it would be useful...


Yes, -transport is intended to be published as an RFC. So is draft-alvestrand-rtcweb-gateways (if the group accepts it).


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


--------------020402050505090300050407-- From nobody Tue Oct 7 09:21:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625BC1A9149 for ; Tue, 7 Oct 2014 09:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBjUBRoHiG0i for ; Tue, 7 Oct 2014 09:21:20 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id F36D31A6FFF for ; Tue, 7 Oct 2014 09:21:19 -0700 (PDT) Received: from userPC (unknown [122.167.82.149]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id D0EDB1908321; Tue, 7 Oct 2014 16:21:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1412698878; bh=DBxsunZAPo7EVhqmbgmZ9WJ9Ev8+bMTWTwWYnvy2L6k=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=KTD7IKpCZXVLuizNBIFspenhJTOtsuSPvAL9zuZAPgvsDjZzbZGvC5YQNxik8+7BM J5URTC4gzfxMdERYw9pzzrpmiunDWQ7BaFU0oLGrdRt8sD7ZZoXeakSynRvfxETy05 SOXFafVR3aqsW2pstfzM2ZqD6tS+akdtmXnoL/6s= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Harald Alvestrand'" , References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> Date: Tue, 7 Oct 2014 21:51:07 +0530 Message-ID: <00f501cfe24a$b8515930$28f40b90$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP3t3ehH0V0UJNhEaGpnZRIRprGZweQ+vQ///tNQCAAG62UIAAAtpwgAYyCWA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020203.543412FE.01AC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hbIcIOjkrzelSxytgNDcoPlDwAY Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2014 16:21:25 -0000 Hi Christer, I have no issue with WebRTC User Agent, WebRTC device, WebRTC endpoint. I have bit trouble with WebRTC compatible endpoint as a entity name as=20 1) It may pass SRTP/data channel=20 2) It is not required to be endpoint but it shall be middle box. WebRTC gateway looks more appropriate entity name in those scenarios. Thanks Partha > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Friday, October 03, 2014 11:06 PM > To: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Definitions of WebRTC entities >=20 > Hi, >=20 > >>DTLS: A webrtc endpoint either uses data channels, which require > dtls, or rtp, whuch requires DTLS-srtp, which requires dtls, so I > figured it > >>was safe to say that dtls was required. > > > >I think it would be better to explicitly indicate the usages for = which > DTLS needs to be supported, ie DTLS-SRTP for RTP and as defined for > data channels. > >Because, DTLS can be used for many different purposes, in different > ways, so just saying =E2=80=9Csupport DTLS=E2=80=9D is unclear. >=20 > In addition, it is probably useful to indicate that an compatible > endpoint may not necessarily terminate all DTLS usages. For example, a > gateway might simply pass through the data channel, and/or the SRTP > traffic. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > Den 3. oktober 2014 14:01:20 CEST, skrev Christer Holmberg > : > Hi, >=20 > First, I personally see no need for all these definitions. >=20 > I think it would be enough to have: >=20 > - WebRTC endpoint (e.g. a browser) > - WebRTC-compatible endpoint (e.g. a gateway) >=20 > If people really think we need more, I won't argue against. I just > think it becomes very messy, and people WILL end up using the wrong > terminology :) >=20 >=20 > Second, you say: >=20 > "Note that support for DTLS, ICE and TURN ARE required for a WebRTC- > compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be > used." >=20 > You already in the bullet list said support of ICE lite, so the text = is > conflicting. >=20 > I am not sure what you mean by "support for TURN". An ICE lite = endpoint > will not create TURN candidates etc. Of course, it may receive media > via a TURN server. >=20 > What do you mean by "support for DTLS"? I think you need to be a = little > more specific (later you do mention DTLS-SRTP in case of > RTP). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: 3. lokakuuta 2014 10:44 > To: rtcweb@ietf.org > Subject: [rtcweb] Definitions of WebRTC entities >=20 > After all the feedback, I've taken another whack at this. >=20 > It seems that the term "WebRTC endpoint" is already used widely enough > that it's worth continuing to use it. So I ended up with the following > suggested text for -overview's definitions. >=20 > Comments? > If this seems OK, I'll emit another -overview next week with these > definitions. >=20 > -------------------------- >=20 > o A WebRTC User Agent (also called an UA or browser) is something > that conforms to both the protocol specification and the Javascript = API > defined above. >=20 > o A WebRTC device is something that conforms to the protocol > specification, but does not > claim to implement the Javascript API. >=20 > o A WebRTC endpoint is either a WebRTC UA or a WebRTC device. >=20 > o A WebRTC-compatible endpoint is an endpoint that is capable of > successfully communicating with a WebRTC endpoint, but may fail to = meet > some requirement of the WebRTC endpoint. This may limit where in the > network such an endpoint can be attached, or may limit the security > guarantees that it offers to others. >=20 > o A WebRTC gateway is a WebRTC-compatible endpoint that mediates > media traffic to non-WebRTC entities. >=20 > ----------------------------- >=20 > FOR TRANSPORT: >=20 > A WebRTC-compatible endpoint is capable of inititating or accepting a > session with a WebRTC endpoint. The following requirements on a WebRTC > endpoint are not required for such success: >=20 > - Support for full ICE. If the endpoint is only ever going to be > attached to the public Internet, it does not need to be able to fix = its > own external address; > ICE-Lite is enough. > - Support for the full suite of MTI codecs for a WebRTC endpoint. In > particular, audio gateways that connect to native G.711 networks may > choose to implement G.711 and not implement Opus. > - Offering BUNDLE or RTCP-MUX > - Using MSID in its offers or answers > more> >=20 > Note that support for DTLS, ICE and TURN ARE required for a WebRTC- > compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be = used. > ________________________________________ >=20 > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Oct 7 09:46:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0361ACE31 for ; Tue, 7 Oct 2014 09:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKMKr2_JRlFX for ; Tue, 7 Oct 2014 09:46:17 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAFC1ACE57 for ; Tue, 7 Oct 2014 09:46:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9E2357C055D; Tue, 7 Oct 2014 18:46:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2QRcJZokayd; Tue, 7 Oct 2014 18:46:14 +0200 (CEST) Received: from [10.100.3.208] (unknown [193.110.199.36]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1BDD57C0550; Tue, 7 Oct 2014 18:46:14 +0200 (CEST) Message-ID: <543418D5.8010509@alvestrand.no> Date: Tue, 07 Oct 2014 18:46:13 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Parthasarathi R , 'Christer Holmberg' , rtcweb@ietf.org References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> In-Reply-To: <00f501cfe24a$b8515930$28f40b90$@co.in> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/q0FX87Fumj_7yuUQ6_EYJuudH2I Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2014 16:46:21 -0000 On 10/07/2014 06:21 PM, Parthasarathi R wrote: > Hi Christer, > > I have no issue with WebRTC User Agent, WebRTC device, WebRTC endpoint. > > I have bit trouble with WebRTC compatible endpoint as a entity name as > > 1) It may pass SRTP/data channel What do you mean by "pass"? That's a slippery term. > 2) It is not required to be endpoint but it shall be middle box. What do you mean by "middle box"? Again, that term is slippery. > > WebRTC gateway looks more appropriate entity name in those scenarios. As written in my proposal, a WebRTC gateway is a WebRTC compatible endpoint. I think you will have to describe more fully what the device you are thinking about looks like; if it's just the WebRTC endpoint functions scattered over a set of boxes, it's possible I may call it a "distributed WebRTC-compatible endpoint". > > Thanks > Partha > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: Friday, October 03, 2014 11:06 PM >> To: Harald Alvestrand; rtcweb@ietf.org >> Subject: Re: [rtcweb] Definitions of WebRTC entities >> >> Hi, >> >>>> DTLS: A webrtc endpoint either uses data channels, which require >> dtls, or rtp, whuch requires DTLS-srtp, which requires dtls, so I >> figured it >>>> was safe to say that dtls was required. >>> I think it would be better to explicitly indicate the usages for which >> DTLS needs to be supported, ie DTLS-SRTP for RTP and as defined for >> data channels. >>> Because, DTLS can be used for many different purposes, in different >> ways, so just saying “support DTLS†is unclear. >> >> In addition, it is probably useful to indicate that an compatible >> endpoint may not necessarily terminate all DTLS usages. For example, a >> gateway might simply pass through the data channel, and/or the SRTP >> traffic. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> Den 3. oktober 2014 14:01:20 CEST, skrev Christer Holmberg >> : >> Hi, >> >> First, I personally see no need for all these definitions. >> >> I think it would be enough to have: >> >> - WebRTC endpoint (e.g. a browser) >> - WebRTC-compatible endpoint (e.g. a gateway) >> >> If people really think we need more, I won't argue against. I just >> think it becomes very messy, and people WILL end up using the wrong >> terminology :) >> >> >> Second, you say: >> >> "Note that support for DTLS, ICE and TURN ARE required for a WebRTC- >> compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be >> used." >> >> You already in the bullet list said support of ICE lite, so the text is >> conflicting. >> >> I am not sure what you mean by "support for TURN". An ICE lite endpoint >> will not create TURN candidates etc. Of course, it may receive media >> via a TURN server. >> >> What do you mean by "support for DTLS"? I think you need to be a little >> more specific (later you do mention DTLS-SRTP in case of >> RTP). >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >> Alvestrand >> Sent: 3. lokakuuta 2014 10:44 >> To: rtcweb@ietf.org >> Subject: [rtcweb] Definitions of WebRTC entities >> >> After all the feedback, I've taken another whack at this. >> >> It seems that the term "WebRTC endpoint" is already used widely enough >> that it's worth continuing to use it. So I ended up with the following >> suggested text for -overview's definitions. >> >> Comments? >> If this seems OK, I'll emit another -overview next week with these >> definitions. >> >> -------------------------- >> >> o A WebRTC User Agent (also called an UA or browser) is something >> that conforms to both the protocol specification and the Javascript API >> defined above. >> >> o A WebRTC device is something that conforms to the protocol >> specification, but does not >> claim to implement the Javascript API. >> >> o A WebRTC endpoint is either a WebRTC UA or a WebRTC device. >> >> o A WebRTC-compatible endpoint is an endpoint that is capable of >> successfully communicating with a WebRTC endpoint, but may fail to meet >> some requirement of the WebRTC endpoint. This may limit where in the >> network such an endpoint can be attached, or may limit the security >> guarantees that it offers to others. >> >> o A WebRTC gateway is a WebRTC-compatible endpoint that mediates >> media traffic to non-WebRTC entities. >> >> ----------------------------- >> >> FOR TRANSPORT: >> >> A WebRTC-compatible endpoint is capable of inititating or accepting a >> session with a WebRTC endpoint. The following requirements on a WebRTC >> endpoint are not required for such success: >> >> - Support for full ICE. If the endpoint is only ever going to be >> attached to the public Internet, it does not need to be able to fix its >> own external address; >> ICE-Lite is enough. >> - Support for the full suite of MTI codecs for a WebRTC endpoint. In >> particular, audio gateways that connect to native G.711 networks may >> choose to implement G.711 and not implement Opus. >> - Offering BUNDLE or RTCP-MUX >> - Using MSID in its offers or answers >> > more> >> >> Note that support for DTLS, ICE and TURN ARE required for a WebRTC- >> compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used. >> ________________________________________ >> >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Tue Oct 7 10:14:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D968F1ACE57 for ; Tue, 7 Oct 2014 10:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAV2FKLZ2fdF for ; Tue, 7 Oct 2014 10:14:12 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DE91ACE63 for ; Tue, 7 Oct 2014 10:14:11 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-aa-54341f61abef Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 42.6A.21432.16F14345; Tue, 7 Oct 2014 19:14:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 19:14:08 +0200 From: Christer Holmberg To: Parthasarathi R , 'Harald Alvestrand' , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Definitions of WebRTC entities Thread-Index: AQHP3t3ehH0V0UJNhEaGpnZRIRprGZweQ+vQ///tNQCAAG62UIAAAtpwgAYyCWCAABEQAA== Date: Tue, 7 Oct 2014 17:14:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46CCA9@ESESSMB209.ericsson.se> References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> In-Reply-To: <00f501cfe24a$b8515930$28f40b90$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvjW6ivEmIwZQvohbH+rrYLCZ/6mO1 WPuvnd2B2ePKhCusHkuW/GTy+DD/C3sAcxSXTUpqTmZZapG+XQJXxq7DtxgL5thXLP/Sy97A eMa2i5GTQ0LAROJW71JWCFtM4sK99WxdjFwcQgJHGSVWztjCCuEsZpSYOWsBexcjBwebgIVE 9z9tkLiIQDOjxLf5S9lBuoWBJu2ct4kRxBYRMJXomnWfEaReRCBMYusfLZAwi4CKxPOTP5hA bF4BX4muaSAjQebfZJJ4N2cf2BWcQHN+bZ7NDGIzAl30/dQasAZmAXGJW0/mM0FcKiCxZM95 ZghbVOLl439QHyhJNC55wgqyl1lAU2L9Ln2IVkWJKd0P2SH2CkqcnPmEZQKj6CwkU2chdMxC 0jELSccCRpZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIGRc3DLb4MdjC+fOx5iFOBgVOLh VfA0DhFiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxK1hrJ XwqVpVdbvTvYlOzLJ/TQeb8fv9vfd39N3594U8JUeKSHX2n3iim7k1pP2Z3/7L0n53Byn9Em cS55JdabWqUXy6Lvv7IpuvZKx4xTx0SeQSEo584pnoyjK/6wu7ose6Gh+uPYyY0aRn+zK1W3 7fH2ynxQUaZeoys2Z+kFyS3Su9rmliixFGckGmoxFxUnAgCpiP9afQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/muOpC7rPZZoRqr2B5iRAFPO2ApA Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2014 17:14:15 -0000 DQpIaSwNCg0KSW4gbXkgb3BpbmlvbiB3ZSBoYXZlIFRXTyB0eXBlcyBvZiBFTkRQT0lOVFM6IHRo b3NlIHRoYXQgc3VwcG9ydCB0aGUgZnVsbCBzZXQgb2YgUlRDV0VCIHRvb2xzZXQgKGUuZy4gYnJv d3NlcnMpIGFuZCB0aG9zZSB3aG8gc3VwcG9ydCBhIHN1YnNldCAoZS5nLiBnYXRld2F5cykuDQoN CkkgZG9uJ3QgcmVhbGx5IGNhcmUgd2hhdCB3ZSBjYWxsIHRoZW0sIGJ1dCB3ZSBzaG91bGRuJ3Qg Y29tZSB1cCB3aXRoIGxvdHMgb2YgZGlmZmVyZW50IG5hbWVzIHRoYXQgcGVvcGxlIGFyZSBnb2lu ZyB0byB1c2Ugd3JvbmcuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXJ0aGFzYXJhdGhpIFIgW21haWx0bzpwYXJ0aGFA cGFydGhhc2FyYXRoaS5jby5pbl0gDQpTZW50OiAwNyBPY3RvYmVyIDIwMTQgMTk6MjENClRvOiBD aHJpc3RlciBIb2xtYmVyZzsgJ0hhcmFsZCBBbHZlc3RyYW5kJzsgcnRjd2ViQGlldGYub3JnDQpT dWJqZWN0OiBSRTogW3J0Y3dlYl0gRGVmaW5pdGlvbnMgb2YgV2ViUlRDIGVudGl0aWVzDQoNCkhp IENocmlzdGVyLA0KDQpJIGhhdmUgbm8gaXNzdWUgd2l0aCBXZWJSVEMgVXNlciBBZ2VudCwgV2Vi UlRDIGRldmljZSwgV2ViUlRDIGVuZHBvaW50Lg0KDQpJIGhhdmUgYml0IHRyb3VibGUgd2l0aCBX ZWJSVEMgY29tcGF0aWJsZSBlbmRwb2ludCBhcyBhIGVudGl0eSBuYW1lIGFzIA0KDQoxKSBJdCBt YXkgcGFzcyBTUlRQL2RhdGEgY2hhbm5lbA0KMikgSXQgaXMgbm90IHJlcXVpcmVkIHRvIGJlIGVu ZHBvaW50IGJ1dCBpdCBzaGFsbCBiZSBtaWRkbGUgYm94Lg0KDQpXZWJSVEMgZ2F0ZXdheSBsb29r cyBtb3JlIGFwcHJvcHJpYXRlIGVudGl0eSBuYW1lIGluIHRob3NlIHNjZW5hcmlvcy4NCg0KVGhh bmtzDQpQYXJ0aGENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGN3 ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVy IA0KPiBIb2xtYmVyZw0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMDMsIDIwMTQgMTE6MDYgUE0N Cj4gVG86IEhhcmFsZCBBbHZlc3RyYW5kOyBydGN3ZWJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtydGN3ZWJdIERlZmluaXRpb25zIG9mIFdlYlJUQyBlbnRpdGllcw0KPiANCj4gSGksDQo+IA0K PiA+PkRUTFM6IEEgd2VicnRjIGVuZHBvaW50IGVpdGhlciB1c2VzIGRhdGEgY2hhbm5lbHMsIHdo aWNoIHJlcXVpcmUNCj4gZHRscywgb3IgcnRwLCB3aHVjaCByZXF1aXJlcyBEVExTLXNydHAsIHdo aWNoIHJlcXVpcmVzIGR0bHMsIHNvIEkgDQo+IGZpZ3VyZWQgaXQNCj4gPj53YXMgc2FmZSB0byBz YXkgdGhhdCBkdGxzIHdhcyByZXF1aXJlZC4NCj4gPg0KPiA+SSB0aGluayBpdCB3b3VsZCBiZSBi ZXR0ZXIgdG8gZXhwbGljaXRseSBpbmRpY2F0ZSB0aGUgdXNhZ2VzIGZvciANCj4gPndoaWNoDQo+ IERUTFMgbmVlZHMgdG8gYmUgc3VwcG9ydGVkLCBpZSBEVExTLVNSVFAgZm9yIFJUUCBhbmQgYXMg ZGVmaW5lZCBmb3IgDQo+IGRhdGEgY2hhbm5lbHMuDQo+ID5CZWNhdXNlLCBEVExTIGNhbiBiZSB1 c2VkIGZvciBtYW55IGRpZmZlcmVudCBwdXJwb3NlcywgaW4gZGlmZmVyZW50DQo+IHdheXMsIHNv IGp1c3Qgc2F5aW5nIOKAnHN1cHBvcnQgRFRMU+KAnSBpcyB1bmNsZWFyLg0KPiANCj4gSW4gYWRk aXRpb24sIGl0IGlzIHByb2JhYmx5IHVzZWZ1bCB0byBpbmRpY2F0ZSB0aGF0IGFuIGNvbXBhdGli bGUgDQo+IGVuZHBvaW50IG1heSBub3QgbmVjZXNzYXJpbHkgdGVybWluYXRlIGFsbCBEVExTIHVz YWdlcy4gRm9yIGV4YW1wbGUsIGEgDQo+IGdhdGV3YXkgbWlnaHQgc2ltcGx5IHBhc3MgdGhyb3Vn aCB0aGUgZGF0YSBjaGFubmVsLCBhbmQvb3IgdGhlIFNSVFAgDQo+IHRyYWZmaWMuDQo+IA0KPiBS ZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gRGVuIDMu IG9rdG9iZXIgMjAxNCAxNDowMToyMCBDRVNULCBza3JldiBDaHJpc3RlciBIb2xtYmVyZw0KPiA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjoNCj4gSGksDQo+IA0KPiBGaXJzdCwgSSBw ZXJzb25hbGx5IHNlZSBubyBuZWVkIGZvciBhbGwgdGhlc2UgZGVmaW5pdGlvbnMuDQo+IA0KPiBJ IHRoaW5rIGl0IHdvdWxkIGJlIGVub3VnaCB0byBoYXZlOg0KPiANCj4gLSBXZWJSVEMgZW5kcG9p bnQgKGUuZy4gYSBicm93c2VyKQ0KPiAtIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IChlLmcu IGEgZ2F0ZXdheSkNCj4gDQo+IElmIHBlb3BsZSByZWFsbHkgdGhpbmsgd2UgbmVlZCBtb3JlLCBJ IHdvbid0IGFyZ3VlIGFnYWluc3QuIEkganVzdCANCj4gdGhpbmsgaXQgYmVjb21lcyB2ZXJ5IG1l c3N5LCBhbmQgcGVvcGxlIFdJTEwgZW5kIHVwIHVzaW5nIHRoZSB3cm9uZyANCj4gdGVybWlub2xv Z3kgOikNCj4gDQo+IA0KPiBTZWNvbmQsIHlvdSBzYXk6DQo+IA0KPiAgIk5vdGUgdGhhdCBzdXBw b3J0IGZvciBEVExTLCBJQ0UgYW5kIFRVUk4gQVJFIHJlcXVpcmVkIGZvciBhIFdlYlJUQy0gDQo+ IGNvbXBhdGlibGUgZW5kcG9pbnQsIGFuZCBpZiBSVFAgaXMgdXNlZCBhdCBhbGwsIERUTFMtU1JU UCBNVVNUIGJlIA0KPiB1c2VkLiINCj4gDQo+IFlvdSBhbHJlYWR5IGluIHRoZSBidWxsZXQgbGlz dCBzYWlkIHN1cHBvcnQgb2YgSUNFIGxpdGUsIHNvIHRoZSB0ZXh0IA0KPiBpcyBjb25mbGljdGlu Zy4NCj4gDQo+IEkgYW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSAic3VwcG9ydCBmb3IgVFVS TiIuIEFuIElDRSBsaXRlIA0KPiBlbmRwb2ludCB3aWxsIG5vdCBjcmVhdGUgVFVSTiBjYW5kaWRh dGVzIGV0Yy4gT2YgY291cnNlLCBpdCBtYXkgDQo+IHJlY2VpdmUgbWVkaWEgdmlhIGEgVFVSTiBz ZXJ2ZXIuDQo+IA0KPiBXaGF0IGRvIHlvdSBtZWFuIGJ5ICJzdXBwb3J0IGZvciBEVExTIj8gSSB0 aGluayB5b3UgbmVlZCB0byBiZSBhIA0KPiBsaXR0bGUgbW9yZSBzcGVjaWZpYyAobGF0ZXIgeW91 IGRvIG1lbnRpb24gRFRMUy1TUlRQIGluIGNhc2Ugb2YgUlRQKS4NCj4gDQo+IFJlZ2FyZHMsDQo+ IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBIYXJhbGQgDQo+IEFsdmVzdHJhbmQNCj4gU2VudDogMy4gbG9rYWt1dXRhIDIwMTQg MTA6NDQNCj4gVG86IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbcnRjd2ViXSBEZWZpbml0 aW9ucyBvZiBXZWJSVEMgZW50aXRpZXMNCj4gDQo+IEFmdGVyIGFsbCB0aGUgZmVlZGJhY2ssIEkn dmUgdGFrZW4gYW5vdGhlciB3aGFjayBhdCB0aGlzLg0KPiANCj4gSXQgc2VlbXMgdGhhdCB0aGUg dGVybSAiV2ViUlRDIGVuZHBvaW50IiBpcyBhbHJlYWR5IHVzZWQgd2lkZWx5IGVub3VnaCANCj4g dGhhdCBpdCdzIHdvcnRoIGNvbnRpbnVpbmcgdG8gdXNlIGl0LiBTbyBJIGVuZGVkIHVwIHdpdGgg dGhlIGZvbGxvd2luZyANCj4gc3VnZ2VzdGVkIHRleHQgZm9yIC1vdmVydmlldydzIGRlZmluaXRp b25zLg0KPiANCj4gQ29tbWVudHM/DQo+IElmIHRoaXMgc2VlbXMgT0ssIEknbGwgZW1pdCBhbm90 aGVyIC1vdmVydmlldyBuZXh0IHdlZWsgd2l0aCB0aGVzZSANCj4gZGVmaW5pdGlvbnMuDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gICAgIG8gIEEgV2ViUlRDIFVzZXIg QWdlbnQgKGFsc28gY2FsbGVkIGFuIFVBIG9yIGJyb3dzZXIpIGlzIHNvbWV0aGluZyANCj4gdGhh dCBjb25mb3JtcyB0byBib3RoIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGFuZCB0aGUgSmF2 YXNjcmlwdCANCj4gQVBJIGRlZmluZWQgYWJvdmUuDQo+IA0KPiAgICAgbyAgQSBXZWJSVEMgZGV2 aWNlIGlzIHNvbWV0aGluZyB0aGF0IGNvbmZvcm1zIHRvIHRoZSBwcm90b2NvbA0KPiAgICAgICAg c3BlY2lmaWNhdGlvbiwgYnV0IGRvZXMgbm90DQo+IGNsYWltIHRvIGltcGxlbWVudCB0aGUgSmF2 YXNjcmlwdCBBUEkuDQo+IA0KPiAgICAgbyAgQSBXZWJSVEMgZW5kcG9pbnQgaXMgZWl0aGVyIGEg V2ViUlRDIFVBIG9yIGEgV2ViUlRDIGRldmljZS4NCj4gDQo+ICAgICBvICBBIFdlYlJUQy1jb21w YXRpYmxlIGVuZHBvaW50IGlzIGFuIGVuZHBvaW50IHRoYXQgaXMgY2FwYWJsZSBvZiANCj4gc3Vj Y2Vzc2Z1bGx5IGNvbW11bmljYXRpbmcgd2l0aCBhIFdlYlJUQyBlbmRwb2ludCwgYnV0IG1heSBm YWlsIHRvIA0KPiBtZWV0IHNvbWUgcmVxdWlyZW1lbnQgb2YgdGhlIFdlYlJUQyBlbmRwb2ludC4g VGhpcyBtYXkgbGltaXQgd2hlcmUgaW4gDQo+IHRoZSBuZXR3b3JrIHN1Y2ggYW4gZW5kcG9pbnQg Y2FuIGJlIGF0dGFjaGVkLCBvciBtYXkgbGltaXQgdGhlIA0KPiBzZWN1cml0eSBndWFyYW50ZWVz IHRoYXQgaXQgb2ZmZXJzIHRvIG90aGVycy4NCj4gDQo+ICAgICBvICBBIFdlYlJUQyBnYXRld2F5 IGlzIGEgV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQgdGhhdCBtZWRpYXRlcyANCj4gbWVkaWEg dHJhZmZpYyB0byBub24tV2ViUlRDIGVudGl0aWVzLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IEZPUiBUUkFOU1BPUlQ6DQo+IA0KPiBBIFdlYlJUQy1jb21wYXRp YmxlIGVuZHBvaW50IGlzIGNhcGFibGUgb2YgaW5pdGl0YXRpbmcgb3IgYWNjZXB0aW5nIGEgDQo+ IHNlc3Npb24gd2l0aCBhIFdlYlJUQyBlbmRwb2ludC4gVGhlIGZvbGxvd2luZyByZXF1aXJlbWVu dHMgb24gYSBXZWJSVEMgDQo+IGVuZHBvaW50IGFyZSBub3QgcmVxdWlyZWQgZm9yIHN1Y2ggc3Vj Y2VzczoNCj4gDQo+IC0gU3VwcG9ydCBmb3IgZnVsbCBJQ0UuIElmIHRoZSBlbmRwb2ludCBpcyBv bmx5IGV2ZXIgZ29pbmcgdG8gYmUgDQo+IGF0dGFjaGVkIHRvIHRoZSBwdWJsaWMgSW50ZXJuZXQs IGl0IGRvZXMgbm90IG5lZWQgdG8gYmUgYWJsZSB0byBmaXggDQo+IGl0cyBvd24gZXh0ZXJuYWwg YWRkcmVzczsgSUNFLUxpdGUgaXMgZW5vdWdoLg0KPiAtIFN1cHBvcnQgZm9yIHRoZSBmdWxsIHN1 aXRlIG9mIE1USSBjb2RlY3MgZm9yIGEgV2ViUlRDIGVuZHBvaW50LiBJbiANCj4gcGFydGljdWxh ciwgYXVkaW8gZ2F0ZXdheXMgdGhhdCBjb25uZWN0IHRvIG5hdGl2ZSBHLjcxMSBuZXR3b3JrcyBt YXkgDQo+IGNob29zZSB0byBpbXBsZW1lbnQgRy43MTEgYW5kIG5vdCBpbXBsZW1lbnQgT3B1cy4N Cj4gLSBPZmZlcmluZyBCVU5ETEUgb3IgUlRDUC1NVVgNCj4gLSBVc2luZyBNU0lEIGluIGl0cyBv ZmZlcnMgb3IgYW5zd2Vycw0KPiA8c2hvdWxkIGNvbmdlc3Rpb24gY3V0b2ZmIHJlcXVpcmVtZW50 IGJlIGluIG9yIG91dD8+IDx0aGVyZSB3aWxsIGJlDQo+IG1vcmU+DQo+IA0KPiBOb3RlIHRoYXQg c3VwcG9ydCBmb3IgRFRMUywgSUNFIGFuZCBUVVJOIEFSRSByZXF1aXJlZCBmb3IgYSBXZWJSVEMt IA0KPiBjb21wYXRpYmxlIGVuZHBvaW50LCBhbmQgaWYgUlRQIGlzIHVzZWQgYXQgYWxsLCBEVExT LVNSVFAgTVVTVCBiZSB1c2VkLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IA0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiANCj4gLS0NCj4g U2VudCBmcm9tIG15IEFuZHJvaWQgZGV2aWNlIHdpdGggSy05IE1haWwuIFBsZWFzZSBleGN1c2Ug bXkgYnJldml0eS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K From nobody Tue Oct 7 10:34:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A021A70FE for ; Tue, 7 Oct 2014 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KISBM28NuHb7 for ; Tue, 7 Oct 2014 10:34:39 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 630CF1A0361 for ; Tue, 7 Oct 2014 10:34:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7617E7C066F; Tue, 7 Oct 2014 19:34:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmt9nl8axmRe; Tue, 7 Oct 2014 19:34:35 +0200 (CEST) Received: from [10.100.3.208] (unknown [193.110.199.36]) by mork.alvestrand.no (Postfix) with ESMTPSA id 093A37C0560; Tue, 7 Oct 2014 19:34:35 +0200 (CEST) Message-ID: <54342424.8000605@alvestrand.no> Date: Tue, 07 Oct 2014 19:34:28 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Christer Holmberg , Parthasarathi R , "rtcweb@ietf.org" References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <7594FB04B1934943A5C02806D1A2204B1D46CCA9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D46CCA9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ewyzq3umq2MUoYm3Sahvg6Gfob8 Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2014 17:34:43 -0000 On 10/07/2014 07:14 PM, Christer Holmberg wrote: > Hi, > > In my opinion we have TWO types of ENDPOINTS: those that support the full set of RTCWEB toolset (e.g. browsers) and those who support a subset (e.g. gateways). > > I don't really care what we call them, but we shouldn't come up with lots of different names that people are going to use wrong. People have also wanted to claim that something is fully WebRTC-compliant without having a Javascript API on it. That's where the "UA/browser" vs "Device" thing comes in. I'm trying to make everyone happy :-) > > Regards, > > Christer > > > > > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 07 October 2014 19:21 > To: Christer Holmberg; 'Harald Alvestrand'; rtcweb@ietf.org > Subject: RE: [rtcweb] Definitions of WebRTC entities > > Hi Christer, > > I have no issue with WebRTC User Agent, WebRTC device, WebRTC endpoint. > > I have bit trouble with WebRTC compatible endpoint as a entity name as > > 1) It may pass SRTP/data channel > 2) It is not required to be endpoint but it shall be middle box. > > WebRTC gateway looks more appropriate entity name in those scenarios. > > Thanks > Partha > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: Friday, October 03, 2014 11:06 PM >> To: Harald Alvestrand; rtcweb@ietf.org >> Subject: Re: [rtcweb] Definitions of WebRTC entities >> >> Hi, >> >>>> DTLS: A webrtc endpoint either uses data channels, which require >> dtls, or rtp, whuch requires DTLS-srtp, which requires dtls, so I >> figured it >>>> was safe to say that dtls was required. >>> I think it would be better to explicitly indicate the usages for >>> which >> DTLS needs to be supported, ie DTLS-SRTP for RTP and as defined for >> data channels. >>> Because, DTLS can be used for many different purposes, in different >> ways, so just saying “support DTLS†is unclear. >> >> In addition, it is probably useful to indicate that an compatible >> endpoint may not necessarily terminate all DTLS usages. For example, a >> gateway might simply pass through the data channel, and/or the SRTP >> traffic. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> Den 3. oktober 2014 14:01:20 CEST, skrev Christer Holmberg >> : >> Hi, >> >> First, I personally see no need for all these definitions. >> >> I think it would be enough to have: >> >> - WebRTC endpoint (e.g. a browser) >> - WebRTC-compatible endpoint (e.g. a gateway) >> >> If people really think we need more, I won't argue against. I just >> think it becomes very messy, and people WILL end up using the wrong >> terminology :) >> >> >> Second, you say: >> >> "Note that support for DTLS, ICE and TURN ARE required for a WebRTC- >> compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be >> used." >> >> You already in the bullet list said support of ICE lite, so the text >> is conflicting. >> >> I am not sure what you mean by "support for TURN". An ICE lite >> endpoint will not create TURN candidates etc. Of course, it may >> receive media via a TURN server. >> >> What do you mean by "support for DTLS"? I think you need to be a >> little more specific (later you do mention DTLS-SRTP in case of RTP). >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >> Alvestrand >> Sent: 3. lokakuuta 2014 10:44 >> To: rtcweb@ietf.org >> Subject: [rtcweb] Definitions of WebRTC entities >> >> After all the feedback, I've taken another whack at this. >> >> It seems that the term "WebRTC endpoint" is already used widely enough >> that it's worth continuing to use it. So I ended up with the following >> suggested text for -overview's definitions. >> >> Comments? >> If this seems OK, I'll emit another -overview next week with these >> definitions. >> >> -------------------------- >> >> o A WebRTC User Agent (also called an UA or browser) is something >> that conforms to both the protocol specification and the Javascript >> API defined above. >> >> o A WebRTC device is something that conforms to the protocol >> specification, but does not >> claim to implement the Javascript API. >> >> o A WebRTC endpoint is either a WebRTC UA or a WebRTC device. >> >> o A WebRTC-compatible endpoint is an endpoint that is capable of >> successfully communicating with a WebRTC endpoint, but may fail to >> meet some requirement of the WebRTC endpoint. This may limit where in >> the network such an endpoint can be attached, or may limit the >> security guarantees that it offers to others. >> >> o A WebRTC gateway is a WebRTC-compatible endpoint that mediates >> media traffic to non-WebRTC entities. >> >> ----------------------------- >> >> FOR TRANSPORT: >> >> A WebRTC-compatible endpoint is capable of inititating or accepting a >> session with a WebRTC endpoint. The following requirements on a WebRTC >> endpoint are not required for such success: >> >> - Support for full ICE. If the endpoint is only ever going to be >> attached to the public Internet, it does not need to be able to fix >> its own external address; ICE-Lite is enough. >> - Support for the full suite of MTI codecs for a WebRTC endpoint. In >> particular, audio gateways that connect to native G.711 networks may >> choose to implement G.711 and not implement Opus. >> - Offering BUNDLE or RTCP-MUX >> - Using MSID in its offers or answers >> > more> >> >> Note that support for DTLS, ICE and TURN ARE required for a WebRTC- >> compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be used. >> ________________________________________ >> >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Tue Oct 7 11:27:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205A91A01A5 for ; Tue, 7 Oct 2014 11:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2YMcmnZnRuW for ; Tue, 7 Oct 2014 11:27:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E301A012D for ; Tue, 7 Oct 2014 11:27:21 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-a6-543430878b21 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C8.8F.21334.78034345; Tue, 7 Oct 2014 20:27:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 20:27:19 +0200 From: Christer Holmberg To: Harald Alvestrand , Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Definitions of WebRTC entities Thread-Index: AQHP3t3ehH0V0UJNhEaGpnZRIRprGZweQ+vQ///tNQCAAG62UIAAAtpwgAYyCWCAABEQAP//5NcAgAAvRnA= Date: Tue, 7 Oct 2014 18:27:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46CEB3@ESESSMB209.ericsson.se> References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <7594FB04B1934943A5C02806D1A2204B1D46CCA9@ESESSMB209.ericsson.se> <54342424.8000605@alvestrand.no> In-Reply-To: <54342424.8000605@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW67gUmIwaVvmhbH+rrYLCZ/6mO1 WPuvnd2B2ePKhCusHkuW/GTy+DD/C3sAcxSXTUpqTmZZapG+XQJXxqPj+5kLFrhW3Oq9y97A uMe5i5GTQ0LARGLnlG0sELaYxIV769m6GLk4hASOMkps2dXHAuEsZpRY0r0dyOHgYBOwkOj+ pw0SFxFoZJSYfOQbE0i3MMikeZsYQWwRAVOJrln3oewkiRcbNrGC2CwCKhLzz29iA7F5BXwl 1u34wwqx4ACzxNoNb8HO4BTQlXjy4gaYzQh00vdTa8AWMAuIS9x6Mp8J4lQBiSV7zjND2KIS Lx//Y4WwlSQalzxhBTmUWUBTYv0ufYhWRYkp3Q/ZIfYKSpyc+YRlAqPoLCRTZyF0zELSMQtJ xwJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgbFzcMtv3R2Mq187HmIU4GBU4uFV8DQO EWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjD1HA9bdFDRd p/YqYoor+8QzroKfp+2XuvntRbjFflNxkftX1nNG3dwgnGT8Yt1Eo9maZVPdN9/892dS/oPF BYb7UyPmrd4brjM98fu9nv1Py5lf3FmWsPlN4JKESXOeRW4Ksz3sxnyJ5bnWYzbxPe5/pJzZ G3hfGtQ3NWy7HnSLabJ56IWkd51KLMUZiYZazEXFiQBntoFXfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AGY-Qmp81O6bbp-O03DBzOFhO74 Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2014 18:27:26 -0000 SGksDQoNCj4+IEluIG15IG9waW5pb24gd2UgaGF2ZSBUV08gdHlwZXMgb2YgRU5EUE9JTlRTOiB0 aG9zZSB0aGF0IHN1cHBvcnQgdGhlID4+IGZ1bGwgc2V0IG9mIFJUQ1dFQiB0b29sc2V0IChlLmcu IGJyb3dzZXJzKSBhbmQgdGhvc2Ugd2hvIHN1cHBvcnQgYSBzdWJzZXQgPj4gKGUuZy4gZ2F0ZXdh eXMpLg0KPj4NCj4+IEkgZG9uJ3QgcmVhbGx5IGNhcmUgd2hhdCB3ZSBjYWxsIHRoZW0sIGJ1dCB3 ZSBzaG91bGRuJ3QgY29tZSB1cCB3aXRoIGxvdHMgPj4gb2YgZGlmZmVyZW50IG5hbWVzIHRoYXQg cGVvcGxlIGFyZSBnb2luZyB0byB1c2Ugd3JvbmcuDQo+DQo+IFBlb3BsZSBoYXZlIGFsc28gd2Fu dGVkIHRvIGNsYWltIHRoYXQgc29tZXRoaW5nIGlzIGZ1bGx5IFdlYlJUQy1jb21wbGlhbnQgPiB3 aXRob3V0IGhhdmluZyBhIEphdmFzY3JpcHQgQVBJIG9uIGl0LiBUaGF0J3Mgd2hlcmUgdGhlICJV QS9icm93c2VyIiB2cyANCj4gIkRldmljZSIgdGhpbmcgY29tZXMgaW4uDQoNCkkgdW5kZXJzdGFu ZC4gQnV0LCB3aHkgY2FuJ3Qgd2UgdGhlbiBzaW1wbHkgc2F5ICJKYXZhU2NyaXB0IGVuYWJsZWQg V2ViUlRDIGVuZHBvaW50Iiwgb3Igc29tZXRoaW5nIHNpbWlsYXI/IA0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCg0KSSdtIHRyeWluZyB0byBtYWtlIGV2ZXJ5b25lIGhhcHB5IDotKQ0KDQo+ DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFBhcnRoYXNhcmF0aGkgUiBbbWFpbHRvOnBhcnRoYUBwYXJ0 aGFzYXJhdGhpLmNvLmluXQ0KPiBTZW50OiAwNyBPY3RvYmVyIDIwMTQgMTk6MjENCj4gVG86IENo cmlzdGVyIEhvbG1iZXJnOyAnSGFyYWxkIEFsdmVzdHJhbmQnOyBydGN3ZWJAaWV0Zi5vcmcNCj4g U3ViamVjdDogUkU6IFtydGN3ZWJdIERlZmluaXRpb25zIG9mIFdlYlJUQyBlbnRpdGllcw0KPg0K PiBIaSBDaHJpc3RlciwNCj4NCj4gSSBoYXZlIG5vIGlzc3VlIHdpdGggV2ViUlRDIFVzZXIgQWdl bnQsIFdlYlJUQyBkZXZpY2UsIFdlYlJUQyBlbmRwb2ludC4NCj4NCj4gSSBoYXZlIGJpdCB0cm91 YmxlIHdpdGggV2ViUlRDIGNvbXBhdGlibGUgZW5kcG9pbnQgYXMgYSBlbnRpdHkgbmFtZSBhcw0K Pg0KPiAxKSBJdCBtYXkgcGFzcyBTUlRQL2RhdGEgY2hhbm5lbA0KPiAyKSBJdCBpcyBub3QgcmVx dWlyZWQgdG8gYmUgZW5kcG9pbnQgYnV0IGl0IHNoYWxsIGJlIG1pZGRsZSBib3guDQo+DQo+IFdl YlJUQyBnYXRld2F5IGxvb2tzIG1vcmUgYXBwcm9wcmlhdGUgZW50aXR5IG5hbWUgaW4gdGhvc2Ug c2NlbmFyaW9zLg0KPg0KPiBUaGFua3MNCj4gUGFydGhhDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciANCj4+IEhvbG1iZXJnDQo+PiBTZW50OiBGcmlkYXks IE9jdG9iZXIgMDMsIDIwMTQgMTE6MDYgUE0NCj4+IFRvOiBIYXJhbGQgQWx2ZXN0cmFuZDsgcnRj d2ViQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRGVmaW5pdGlvbnMgb2YgV2Vi UlRDIGVudGl0aWVzDQo+Pg0KPj4gSGksDQo+Pg0KPj4+PiBEVExTOiBBIHdlYnJ0YyBlbmRwb2lu dCBlaXRoZXIgdXNlcyBkYXRhIGNoYW5uZWxzLCB3aGljaCByZXF1aXJlDQo+PiBkdGxzLCBvciBy dHAsIHdodWNoIHJlcXVpcmVzIERUTFMtc3J0cCwgd2hpY2ggcmVxdWlyZXMgZHRscywgc28gSSAN Cj4+IGZpZ3VyZWQgaXQNCj4+Pj4gd2FzIHNhZmUgdG8gc2F5IHRoYXQgZHRscyB3YXMgcmVxdWly ZWQuDQo+Pj4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZXhwbGljaXRseSBpbmRpY2F0 ZSB0aGUgdXNhZ2VzIGZvciANCj4+PiB3aGljaA0KPj4gRFRMUyBuZWVkcyB0byBiZSBzdXBwb3J0 ZWQsIGllIERUTFMtU1JUUCBmb3IgUlRQIGFuZCBhcyBkZWZpbmVkIGZvciANCj4+IGRhdGEgY2hh bm5lbHMuDQo+Pj4gQmVjYXVzZSwgRFRMUyBjYW4gYmUgdXNlZCBmb3IgbWFueSBkaWZmZXJlbnQg cHVycG9zZXMsIGluIGRpZmZlcmVudA0KPj4gd2F5cywgc28ganVzdCBzYXlpbmcg4oCcc3VwcG9y dCBEVExT4oCdIGlzIHVuY2xlYXIuDQo+Pg0KPj4gSW4gYWRkaXRpb24sIGl0IGlzIHByb2JhYmx5 IHVzZWZ1bCB0byBpbmRpY2F0ZSB0aGF0IGFuIGNvbXBhdGlibGUgDQo+PiBlbmRwb2ludCBtYXkg bm90IG5lY2Vzc2FyaWx5IHRlcm1pbmF0ZSBhbGwgRFRMUyB1c2FnZXMuIEZvciBleGFtcGxlLCAN Cj4+IGEgZ2F0ZXdheSBtaWdodCBzaW1wbHkgcGFzcyB0aHJvdWdoIHRoZSBkYXRhIGNoYW5uZWws IGFuZC9vciB0aGUgU1JUUCANCj4+IHRyYWZmaWMuDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBD aHJpc3Rlcg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gRGVuIDMuIG9rdG9iZXIgMjAxNCAx NDowMToyMCBDRVNULCBza3JldiBDaHJpc3RlciBIb2xtYmVyZw0KPj4gPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT46DQo+PiBIaSwNCj4+DQo+PiBGaXJzdCwgSSBwZXJzb25hbGx5IHNl ZSBubyBuZWVkIGZvciBhbGwgdGhlc2UgZGVmaW5pdGlvbnMuDQo+Pg0KPj4gSSB0aGluayBpdCB3 b3VsZCBiZSBlbm91Z2ggdG8gaGF2ZToNCj4+DQo+PiAtIFdlYlJUQyBlbmRwb2ludCAoZS5nLiBh IGJyb3dzZXIpDQo+PiAtIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IChlLmcuIGEgZ2F0ZXdh eSkNCj4+DQo+PiBJZiBwZW9wbGUgcmVhbGx5IHRoaW5rIHdlIG5lZWQgbW9yZSwgSSB3b24ndCBh cmd1ZSBhZ2FpbnN0LiBJIGp1c3QgDQo+PiB0aGluayBpdCBiZWNvbWVzIHZlcnkgbWVzc3ksIGFu ZCBwZW9wbGUgV0lMTCBlbmQgdXAgdXNpbmcgdGhlIHdyb25nIA0KPj4gdGVybWlub2xvZ3kgOikN Cj4+DQo+Pg0KPj4gU2Vjb25kLCB5b3Ugc2F5Og0KPj4NCj4+ICAiTm90ZSB0aGF0IHN1cHBvcnQg Zm9yIERUTFMsIElDRSBhbmQgVFVSTiBBUkUgcmVxdWlyZWQgZm9yIGEgV2ViUlRDLSANCj4+IGNv bXBhdGlibGUgZW5kcG9pbnQsIGFuZCBpZiBSVFAgaXMgdXNlZCBhdCBhbGwsIERUTFMtU1JUUCBN VVNUIGJlIA0KPj4gdXNlZC4iDQo+Pg0KPj4gWW91IGFscmVhZHkgaW4gdGhlIGJ1bGxldCBsaXN0 IHNhaWQgc3VwcG9ydCBvZiBJQ0UgbGl0ZSwgc28gdGhlIHRleHQgDQo+PiBpcyBjb25mbGljdGlu Zy4NCj4+DQo+PiBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgInN1cHBvcnQgZm9yIFRV Uk4iLiBBbiBJQ0UgbGl0ZSANCj4+IGVuZHBvaW50IHdpbGwgbm90IGNyZWF0ZSBUVVJOIGNhbmRp ZGF0ZXMgZXRjLiBPZiBjb3Vyc2UsIGl0IG1heSANCj4+IHJlY2VpdmUgbWVkaWEgdmlhIGEgVFVS TiBzZXJ2ZXIuDQo+Pg0KPj4gV2hhdCBkbyB5b3UgbWVhbiBieSAic3VwcG9ydCBmb3IgRFRMUyI/ IEkgdGhpbmsgeW91IG5lZWQgdG8gYmUgYSANCj4+IGxpdHRsZSBtb3JlIHNwZWNpZmljIChsYXRl ciB5b3UgZG8gbWVudGlvbiBEVExTLVNSVFAgaW4gY2FzZSBvZiBSVFApLg0KPj4NCj4+IFJlZ2Fy ZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+Pg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBIYXJhbGQgDQo+PiBBbHZlc3RyYW5kDQo+PiBTZW50OiAzLiBsb2th a3V1dGEgMjAxNCAxMDo0NA0KPj4gVG86IHJ0Y3dlYkBpZXRmLm9yZw0KPj4gU3ViamVjdDogW3J0 Y3dlYl0gRGVmaW5pdGlvbnMgb2YgV2ViUlRDIGVudGl0aWVzDQo+Pg0KPj4gQWZ0ZXIgYWxsIHRo ZSBmZWVkYmFjaywgSSd2ZSB0YWtlbiBhbm90aGVyIHdoYWNrIGF0IHRoaXMuDQo+Pg0KPj4gSXQg c2VlbXMgdGhhdCB0aGUgdGVybSAiV2ViUlRDIGVuZHBvaW50IiBpcyBhbHJlYWR5IHVzZWQgd2lk ZWx5IA0KPj4gZW5vdWdoIHRoYXQgaXQncyB3b3J0aCBjb250aW51aW5nIHRvIHVzZSBpdC4gU28g SSBlbmRlZCB1cCB3aXRoIHRoZSANCj4+IGZvbGxvd2luZyBzdWdnZXN0ZWQgdGV4dCBmb3IgLW92 ZXJ2aWV3J3MgZGVmaW5pdGlvbnMuDQo+Pg0KPj4gQ29tbWVudHM/DQo+PiBJZiB0aGlzIHNlZW1z IE9LLCBJJ2xsIGVtaXQgYW5vdGhlciAtb3ZlcnZpZXcgbmV4dCB3ZWVrIHdpdGggdGhlc2UgDQo+ PiBkZWZpbml0aW9ucy4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+ ICAgICBvICBBIFdlYlJUQyBVc2VyIEFnZW50IChhbHNvIGNhbGxlZCBhbiBVQSBvciBicm93c2Vy KSBpcyANCj4+IHNvbWV0aGluZyB0aGF0IGNvbmZvcm1zIHRvIGJvdGggdGhlIHByb3RvY29sIHNw ZWNpZmljYXRpb24gYW5kIHRoZSANCj4+IEphdmFzY3JpcHQgQVBJIGRlZmluZWQgYWJvdmUuDQo+ Pg0KPj4gICAgIG8gIEEgV2ViUlRDIGRldmljZSBpcyBzb21ldGhpbmcgdGhhdCBjb25mb3JtcyB0 byB0aGUgcHJvdG9jb2wNCj4+ICAgICAgICBzcGVjaWZpY2F0aW9uLCBidXQgZG9lcyBub3QNCj4+ IGNsYWltIHRvIGltcGxlbWVudCB0aGUgSmF2YXNjcmlwdCBBUEkuDQo+Pg0KPj4gICAgIG8gIEEg V2ViUlRDIGVuZHBvaW50IGlzIGVpdGhlciBhIFdlYlJUQyBVQSBvciBhIFdlYlJUQyBkZXZpY2Uu DQo+Pg0KPj4gICAgIG8gIEEgV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQgaXMgYW4gZW5kcG9p bnQgdGhhdCBpcyBjYXBhYmxlIG9mIA0KPj4gc3VjY2Vzc2Z1bGx5IGNvbW11bmljYXRpbmcgd2l0 aCBhIFdlYlJUQyBlbmRwb2ludCwgYnV0IG1heSBmYWlsIHRvIA0KPj4gbWVldCBzb21lIHJlcXVp cmVtZW50IG9mIHRoZSBXZWJSVEMgZW5kcG9pbnQuIFRoaXMgbWF5IGxpbWl0IHdoZXJlIGluIA0K Pj4gdGhlIG5ldHdvcmsgc3VjaCBhbiBlbmRwb2ludCBjYW4gYmUgYXR0YWNoZWQsIG9yIG1heSBs aW1pdCB0aGUgDQo+PiBzZWN1cml0eSBndWFyYW50ZWVzIHRoYXQgaXQgb2ZmZXJzIHRvIG90aGVy cy4NCj4+DQo+PiAgICAgbyAgQSBXZWJSVEMgZ2F0ZXdheSBpcyBhIFdlYlJUQy1jb21wYXRpYmxl IGVuZHBvaW50IHRoYXQgbWVkaWF0ZXMgDQo+PiBtZWRpYSB0cmFmZmljIHRvIG5vbi1XZWJSVEMg ZW50aXRpZXMuDQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiBG T1IgVFJBTlNQT1JUOg0KPj4NCj4+IEEgV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQgaXMgY2Fw YWJsZSBvZiBpbml0aXRhdGluZyBvciBhY2NlcHRpbmcgYSANCj4+IHNlc3Npb24gd2l0aCBhIFdl YlJUQyBlbmRwb2ludC4gVGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHMgb24gYSANCj4+IFdlYlJU QyBlbmRwb2ludCBhcmUgbm90IHJlcXVpcmVkIGZvciBzdWNoIHN1Y2Nlc3M6DQo+Pg0KPj4gLSBT dXBwb3J0IGZvciBmdWxsIElDRS4gSWYgdGhlIGVuZHBvaW50IGlzIG9ubHkgZXZlciBnb2luZyB0 byBiZSANCj4+IGF0dGFjaGVkIHRvIHRoZSBwdWJsaWMgSW50ZXJuZXQsIGl0IGRvZXMgbm90IG5l ZWQgdG8gYmUgYWJsZSB0byBmaXggDQo+PiBpdHMgb3duIGV4dGVybmFsIGFkZHJlc3M7IElDRS1M aXRlIGlzIGVub3VnaC4NCj4+IC0gU3VwcG9ydCBmb3IgdGhlIGZ1bGwgc3VpdGUgb2YgTVRJIGNv ZGVjcyBmb3IgYSBXZWJSVEMgZW5kcG9pbnQuIEluIA0KPj4gcGFydGljdWxhciwgYXVkaW8gZ2F0 ZXdheXMgdGhhdCBjb25uZWN0IHRvIG5hdGl2ZSBHLjcxMSBuZXR3b3JrcyBtYXkgDQo+PiBjaG9v c2UgdG8gaW1wbGVtZW50IEcuNzExIGFuZCBub3QgaW1wbGVtZW50IE9wdXMuDQo+PiAtIE9mZmVy aW5nIEJVTkRMRSBvciBSVENQLU1VWA0KPj4gLSBVc2luZyBNU0lEIGluIGl0cyBvZmZlcnMgb3Ig YW5zd2VycyA8c2hvdWxkIGNvbmdlc3Rpb24gY3V0b2ZmIA0KPj4gcmVxdWlyZW1lbnQgYmUgaW4g b3Igb3V0Pz4gPHRoZXJlIHdpbGwgYmUNCj4+IG1vcmU+DQo+Pg0KPj4gTm90ZSB0aGF0IHN1cHBv cnQgZm9yIERUTFMsIElDRSBhbmQgVFVSTiBBUkUgcmVxdWlyZWQgZm9yIGEgV2ViUlRDLSANCj4+ IGNvbXBhdGlibGUgZW5kcG9pbnQsIGFuZCBpZiBSVFAgaXMgdXNlZCBhdCBhbGwsIERUTFMtU1JU UCBNVVNUIGJlIHVzZWQuDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pg0KPj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPj4gcnRjd2ViQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4NCj4+IC0tDQo+ PiBTZW50IGZyb20gbXkgQW5kcm9pZCBkZXZpY2Ugd2l0aCBLLTkgTWFpbC4gUGxlYXNlIGV4Y3Vz ZSBteSBicmV2aXR5Lg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KDQotLQ0KU3Vy dmVpbGxhbmNlIGlzIHBlcnZhc2l2ZS4gR28gRGFyay4NCg0K From nobody Tue Oct 7 20:52:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763C1A908B for ; Tue, 7 Oct 2014 20:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1glkV4B6c13V for ; Tue, 7 Oct 2014 20:51:59 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9F31A9076 for ; Tue, 7 Oct 2014 20:51:59 -0700 (PDT) Received: from ppp118-209-179-51.lns20.mel8.internode.on.net ([118.209.179.51]:54615 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XbiIA-0001Ch-4U for rtcweb@ietf.org; Wed, 08 Oct 2014 14:51:58 +1100 Message-ID: <5434B4D9.8000302@nteczone.com> Date: Wed, 08 Oct 2014 14:51:53 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org 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 - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/q7WL4WFJ5tpvtxYcL0dt1h0oIjo Subject: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 03:52:01 -0000 Hello, I have a couple of comments on draft-ietf-rtcweb-stun-consent-freshness-07: 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both "ICE binding requests" and "STUN binding requests". Is there a distinction between them? e.g. "ICE binding requests" refer to 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request indicates a non-extended binding request as per RFC5389. 2) Just to confirm when Consent is first given. Is the 30sec consent period assumed after the initial ICE exchange? I found the second paragraph in cl.4.1 not so clear as it talks about subsequent consent before the initial consent in paragraph 5. I'd suggest modifying it along the lines of: "An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) on an ICE-initiated connection unless the receiving endpoint consents to receive the data. Initial consent is granted as a result of a successful ICE connectivity check on a particular transport address. Consent expires after a fixed amount of time. As a result, subsequent consent MUST be obtained following the procedure described in this document. During ICE restart consent checks MUST continue to be sent on previously validated pair, and MUST be responded to on the previously validated pair, until ICE restart completes." Regards, Christian From nobody Tue Oct 7 23:41:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A5C1A004C for ; Tue, 7 Oct 2014 23:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b2tKlLDEDiM for ; Tue, 7 Oct 2014 23:41:12 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4737B1A0034 for ; Tue, 7 Oct 2014 23:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2192; q=dns/txt; s=iport; t=1412750472; x=1413960072; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QeY6Po9t4rqdRkss2sv+hv1Pc23T6tZhM04N8W88pBE=; b=b6a6jLRKypZ34zajnmlODWkyACeYpD8ZSOTudK5dO91JEBxGDp0p/orC km0Pt0B0i5Vn3KD9u/7DthnM9O3MNlJ6WZ9gcAQtOuVaXnjYt3fMeE9Rn qfR0kLpbRItcVNHtBnzVWk5QSSTXe9c/9lVeGh06TmNDPKvLz2d8uAH8R w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFANHbNFStJA2K/2dsb2JhbABfgw5TWATLEAqGeVQCgQYWAXuEAwEBAQMBAQEBNzQQBwQCAQgRAwECHxAnCx0IAgQBEog2CA3CAQETBJAZMgaERQWPXYIai02BLYNEjRqDf4NjbIEIJByBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,675,1406592000"; d="scan'208";a="84984379" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 08 Oct 2014 06:41:11 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s986fBn5026527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 06:41:11 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.227]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 01:41:10 -0500 From: "Ram Mohan R (rmohanr)" To: Christian Groves , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHP4sLYOK8ZLv2IZUCdaE9iis9zjw== Date: Wed, 8 Oct 2014 06:41:10 +0000 Message-ID: References: <5434B4D9.8000302@nteczone.com> In-Reply-To: <5434B4D9.8000302@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.65.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <65FF91C12EB2F5408DB406BDD764820E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0SHLyUQsVBdrslTCxUN0OgFbWPc Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 06:41:14 -0000 Hi Christian, Thanks for your comments. Please see inline -----Original Message----- From: Christian Groves Date: Wednesday, 8 October 2014 9:21 am To: "rtcweb@ietf.org" Subject: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness >Hello, > >I have a couple of comments on >draft-ietf-rtcweb-stun-consent-freshness-07: > >1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both "ICE >binding requests" and "STUN binding requests". Is there a distinction >between them? e.g. "ICE binding requests" refer to >7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request indicates >a non-extended binding request as per RFC5389. We will change it to STUN binding requests to keep it consistent with the rest of the document. > >2) Just to confirm when Consent is first given. Is the 30sec consent >period assumed after the initial ICE exchange? Paragraph 4 in Section 4.1 has this text. Hope this is sufficient. "The initial Consent to send traffic is obtained by ICE. Consent expires after 30 seconds." > I found the second >paragraph in cl.4.1 not so clear as it talks about subsequent consent >before the initial consent in paragraph 5. I'd suggest modifying it >along the lines of: >"An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, >DTLS), over any transport protocol (e.g., UDP, TCP) on an ICE-initiated >connection unless the receiving endpoint consents to receive the data. >Initial consent is granted as a result of a successful ICE connectivity >check on a particular transport address. Consent expires after a fixed >amount of time. As a result, subsequent consent MUST be obtained >following the procedure described in this document. > >During ICE restart consent checks MUST continue to be sent on previously >validated pair, and MUST be responded to on the previously validated >pair, until ICE restart completes." Sure will make this change. Regards, Ram > >Regards, Christian > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Oct 8 09:39:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D85F1A6FA8 for ; Wed, 8 Oct 2014 09:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9mMfQ2eoOYh for ; Wed, 8 Oct 2014 09:39:32 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.12]) by ietfa.amsl.com (Postfix) with ESMTP id 879511A9108 for ; Wed, 8 Oct 2014 09:39:32 -0700 (PDT) Received: from userPC (unknown [122.167.118.85]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id DFABD1908321; Wed, 8 Oct 2014 16:39:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1412786371; bh=QmYNUpMDHMnOnrSZBlGY1AdsaY7ghjSmgF5k949+hb4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YnfGpPYHefQzU72adDrpXu5D+DmlTcZ75/9LBJ+JU8HccUhiJaoJ5h6AWPgfWE/bd G1wZouQpiKPqj3pmgWKUoovHe/xdEJJ3uSolZvf0QhO8i52eiwO6J6WB01CghEINE/ kbFcoHNaW0gXN8KduFMEAxm+t8K8fvZv4Vhzrsy8= From: "Parthasarathi R" To: "'Harald Alvestrand'" , "'Christer Holmberg'" , References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> In-Reply-To: <543418D5.8010509@alvestrand.no> Date: Wed, 8 Oct 2014 22:09:20 +0530 Message-ID: <006301cfe316$6d3c5590$47b500b0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/iTjpFaJk7lZfMTj6Gy7PZ2tMnGgAw2G+Q Content-Language: en-us X-CTCH-RefID: str=0001.0A020209.543568C3.0194, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4inJlsJIX8Cg-yMHahfszX3E_R4 Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 16:39:37 -0000 Hi Harald, Please read inline. Thanks Partha > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Tuesday, October 07, 2014 10:16 PM > To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org > Subject: Re: [rtcweb] Definitions of WebRTC entities >=20 > On 10/07/2014 06:21 PM, Parthasarathi R wrote: > > Hi Christer, > > > > I have no issue with WebRTC User Agent, WebRTC device, WebRTC > endpoint. > > > > I have bit trouble with WebRTC compatible endpoint as a entity name > as > > > > 1) It may pass SRTP/data channel > What do you mean by "pass"? That's a slippery term. "relay" will be more appropriate term as mentioned in Sec 5 = Para 2 of draft-alvestrand-rtcweb-gateways. > > 2) It is not required to be endpoint but it shall be middle box. > What do you mean by "middle box"? Again, that term is slippery. I intent to say that the entity which is between two endpoints = and it does not end any media session itself. Here, The confusion is = that WebRTC compatible endpoint which is not an endpoint but it is a = middle box. > > > > WebRTC gateway looks more appropriate entity name in those = scenarios. >=20 > As written in my proposal, a WebRTC gateway is a WebRTC compatible > endpoint. >=20 As per your proposal, we need to define WebRTC compatible = endpoint first which is super set of WebRTC gateway. Then, we need to = clarify which kind of WebRTC compatible endpoint qualify as WebRTC = gateway. But Christer wishes to have only two definition (Full/Subset). = > I think you will have to describe more fully what the device you are > thinking about looks like; if it's just the WebRTC endpoint functions > scattered over a set of boxes, it's possible I may call it a > "distributed WebRTC-compatible endpoint". >=20 > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer > >> Holmberg > >> Sent: Friday, October 03, 2014 11:06 PM > >> To: Harald Alvestrand; rtcweb@ietf.org > >> Subject: Re: [rtcweb] Definitions of WebRTC entities > >> > >> Hi, > >> > >>>> DTLS: A webrtc endpoint either uses data channels, which require > >> dtls, or rtp, whuch requires DTLS-srtp, which requires dtls, so I > >> figured it > >>>> was safe to say that dtls was required. > >>> I think it would be better to explicitly indicate the usages for > which > >> DTLS needs to be supported, ie DTLS-SRTP for RTP and as defined for > >> data channels. > >>> Because, DTLS can be used for many different purposes, in = different > >> ways, so just saying =E2=80=9Csupport DTLS=E2=80=9D is unclear. > >> > >> In addition, it is probably useful to indicate that an compatible > >> endpoint may not necessarily terminate all DTLS usages. For = example, > a > >> gateway might simply pass through the data channel, and/or the SRTP > >> traffic. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> > >> > >> Den 3. oktober 2014 14:01:20 CEST, skrev Christer Holmberg > >> : > >> Hi, > >> > >> First, I personally see no need for all these definitions. > >> > >> I think it would be enough to have: > >> > >> - WebRTC endpoint (e.g. a browser) > >> - WebRTC-compatible endpoint (e.g. a gateway) > >> > >> If people really think we need more, I won't argue against. I just > >> think it becomes very messy, and people WILL end up using the wrong > >> terminology :) > >> > >> > >> Second, you say: > >> > >> "Note that support for DTLS, ICE and TURN ARE required for a > WebRTC- > >> compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be > >> used." > >> > >> You already in the bullet list said support of ICE lite, so the = text > is > >> conflicting. > >> > >> I am not sure what you mean by "support for TURN". An ICE lite > endpoint > >> will not create TURN candidates etc. Of course, it may receive = media > >> via a TURN server. > >> > >> What do you mean by "support for DTLS"? I think you need to be a > little > >> more specific (later you do mention DTLS-SRTP in case of > >> RTP). > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> -----Original Message----- > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > >> Alvestrand > >> Sent: 3. lokakuuta 2014 10:44 > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] Definitions of WebRTC entities > >> > >> After all the feedback, I've taken another whack at this. > >> > >> It seems that the term "WebRTC endpoint" is already used widely > enough > >> that it's worth continuing to use it. So I ended up with the > following > >> suggested text for -overview's definitions. > >> > >> Comments? > >> If this seems OK, I'll emit another -overview next week with these > >> definitions. > >> > >> -------------------------- > >> > >> o A WebRTC User Agent (also called an UA or browser) is > something > >> that conforms to both the protocol specification and the Javascript > API > >> defined above. > >> > >> o A WebRTC device is something that conforms to the protocol > >> specification, but does not > >> claim to implement the Javascript API. > >> > >> o A WebRTC endpoint is either a WebRTC UA or a WebRTC device. > >> > >> o A WebRTC-compatible endpoint is an endpoint that is capable > of > >> successfully communicating with a WebRTC endpoint, but may fail to > meet > >> some requirement of the WebRTC endpoint. This may limit where in = the > >> network such an endpoint can be attached, or may limit the security > >> guarantees that it offers to others. > >> > >> o A WebRTC gateway is a WebRTC-compatible endpoint that > mediates > >> media traffic to non-WebRTC entities. > >> > >> ----------------------------- > >> > >> FOR TRANSPORT: > >> > >> A WebRTC-compatible endpoint is capable of inititating or accepting > a > >> session with a WebRTC endpoint. The following requirements on a > WebRTC > >> endpoint are not required for such success: > >> > >> - Support for full ICE. If the endpoint is only ever going to be > >> attached to the public Internet, it does not need to be able to fix > its > >> own external address; > >> ICE-Lite is enough. > >> - Support for the full suite of MTI codecs for a WebRTC endpoint. = In > >> particular, audio gateways that connect to native G.711 networks = may > >> choose to implement G.711 and not implement Opus. > >> - Offering BUNDLE or RTCP-MUX > >> - Using MSID in its offers or answers > >> >> more> > >> > >> Note that support for DTLS, ICE and TURN ARE required for a WebRTC- > >> compatible endpoint, and if RTP is used at all, DTLS-SRTP MUST be > used. > >> ________________________________________ > >> > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > >> -- > >> Sent from my Android device with K-9 Mail. Please excuse my = brevity. > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > -- > Surveillance is pervasive. Go Dark. From nobody Wed Oct 8 19:00:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18EE1A8945 for ; Wed, 8 Oct 2014 18:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2Vv0l7ftXBK for ; Wed, 8 Oct 2014 18:59:56 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0D71A893F for ; Wed, 8 Oct 2014 18:59:56 -0700 (PDT) Received: from ppp118-209-249-5.lns20.mel8.internode.on.net ([118.209.249.5]:53685 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xc318-00073J-V1; Thu, 09 Oct 2014 12:59:47 +1100 Message-ID: <5435EC15.3040908@nteczone.com> Date: Thu, 09 Oct 2014 12:59:49 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" References: <5434B4D9.8000302@nteczone.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 - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Pm0-u12z9O1KBNqEcFTrKOadRlo Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 01:59:58 -0000 Hello Ram, Thanks for the response. A further question. The draft focuses on sender behaviour with regards to consent, i.e. it indicates that an endpoint must not send data if consent hasn't been granted. What about receiver behaviour? E.g. what happens if the sending end point is not well behaved and sends application data beyond the consent period, what should the receiver do? Regards, Christian On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote: > Hi Christian, > > Thanks for your comments. Please see inline > > -----Original Message----- > From: Christian Groves > Date: Wednesday, 8 October 2014 9:21 am > To: "rtcweb@ietf.org" > Subject: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness > >> Hello, >> >> I have a couple of comments on >> draft-ietf-rtcweb-stun-consent-freshness-07: >> >> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both "ICE >> binding requests" and "STUN binding requests". Is there a distinction >> between them? e.g. "ICE binding requests" refer to >> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request indicates >> a non-extended binding request as per RFC5389. > We will change it to STUN binding requests to keep it consistent with the > rest of the document. > >> 2) Just to confirm when Consent is first given. Is the 30sec consent >> period assumed after the initial ICE exchange? > Paragraph 4 in Section 4.1 has this text. Hope this is sufficient. > > "The initial Consent to send traffic is obtained by ICE. Consent > expires after 30 seconds." > > >> I found the second >> paragraph in cl.4.1 not so clear as it talks about subsequent consent >> before the initial consent in paragraph 5. I'd suggest modifying it >> along the lines of: >> "An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, >> DTLS), over any transport protocol (e.g., UDP, TCP) on an ICE-initiated >> connection unless the receiving endpoint consents to receive the data. >> Initial consent is granted as a result of a successful ICE connectivity >> check on a particular transport address. Consent expires after a fixed >> amount of time. As a result, subsequent consent MUST be obtained >> following the procedure described in this document. >> >> During ICE restart consent checks MUST continue to be sent on previously >> validated pair, and MUST be responded to on the previously validated >> pair, until ICE restart completes." > Sure will make this change. > > Regards, > Ram > >> Regards, Christian >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Wed Oct 8 23:42:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD9F1A910A for ; Wed, 8 Oct 2014 23:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWDBWuGmYagO for ; Wed, 8 Oct 2014 23:42:55 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B98E1A9107 for ; Wed, 8 Oct 2014 23:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3740; q=dns/txt; s=iport; t=1412836975; x=1414046575; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3OZakz5KBAyLZIwUMTD5ZKBog4QXmQdbik9k4Kok1as=; b=b3uu8RUMwv2O2QzWSsPrzKPqk5eGXrCn1GHxwHl8sxzq3wYsants0ut6 sdR5LFaSvs/U5pKFawFPB1H5hH9vkfCqPXtptZs6E2mRxh+jhmbUQuSJC MD7iaGQEujLiAvgEQJBdrhsbrknzpGOSFQELywvA0Aof1l6kVy5xqfR6T M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAMstNlStJA2E/2dsb2JhbABfgw5TWATLaAqGeVQCgQQWAXuEAwEBAQMBAQEBNzQXBAIBCBEDAQEBAQoUCQcnCxQJCAIEARIIiC4IDcVAARMEkBMGMgaDJ4EeBZF3jHyDRY0bg3+DY2yBBgIFGQIEHIECAQEB X-IronPort-AV: E=Sophos;i="5.04,683,1406592000"; d="scan'208";a="85335283" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 09 Oct 2014 06:42:54 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s996gssP012330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 06:42:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 01:42:54 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Christian Groves , "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHP4qtCUX66zMXLWE+lLN2cNcLkkJwmFCwAgAFDuYD///etwA== Date: Thu, 9 Oct 2014 06:42:53 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> References: <5434B4D9.8000302@nteczone.com> <5435EC15.3040908@nteczone.com> In-Reply-To: <5435EC15.3040908@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hov1bj-mO3kKfeB0EqlYdFAt1KA Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 06:42:57 -0000 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian > Groves > Sent: Thursday, October 09, 2014 7:30 AM > To: Ram Mohan R (rmohanr); rtcweb@ietf.org > Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshnes= s >=20 > Hello Ram, >=20 > Thanks for the response. A further question. The draft focuses on sender > behaviour with regards to consent, i.e. it indicates that an endpoint mus= t not > send data if consent hasn't been granted. What about receiver behaviour? > E.g. what happens if the sending end point is not well behaved and sends > application data beyond the consent period, what should the receiver do ? The receiver can use DTLS fatal error to immediately revoke the consent. Bu= t if sender does not care about consent revocation then the receiver has to= rely on other techniques (like closing the FW mapping etc.). The javascri= pt may be malicious, hence consent checks are done by the browser (which se= rves as user's TCB)) and browser has to be trusted to do the right thing. -Tiru >=20 > Regards, Christian >=20 > On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote: > > Hi Christian, > > > > Thanks for your comments. Please see inline > > > > -----Original Message----- > > From: Christian Groves > > Date: Wednesday, 8 October 2014 9:21 am > > To: "rtcweb@ietf.org" > > Subject: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness > > > >> Hello, > >> > >> I have a couple of comments on > >> draft-ietf-rtcweb-stun-consent-freshness-07: > >> > >> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both > >> "ICE binding requests" and "STUN binding requests". Is there a > >> distinction between them? e.g. "ICE binding requests" refer to > >> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request > >> indicates a non-extended binding request as per RFC5389. > > We will change it to STUN binding requests to keep it consistent with > > the rest of the document. > > > >> 2) Just to confirm when Consent is first given. Is the 30sec consent > >> period assumed after the initial ICE exchange? > > Paragraph 4 in Section 4.1 has this text. Hope this is sufficient. > > > > "The initial Consent to send traffic is obtained by ICE. Consent > > expires after 30 seconds." > > > > > >> I found the second > >> paragraph in cl.4.1 not so clear as it talks about subsequent consent > >> before the initial consent in paragraph 5. I'd suggest modifying it > >> along the lines of: > >> "An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, > >> DTLS), over any transport protocol (e.g., UDP, TCP) on an > >> ICE-initiated connection unless the receiving endpoint consents to rec= eive > the data. > >> Initial consent is granted as a result of a successful ICE > >> connectivity check on a particular transport address. Consent expires > >> after a fixed amount of time. As a result, subsequent consent MUST be > >> obtained following the procedure described in this document. > >> > >> During ICE restart consent checks MUST continue to be sent on > >> previously validated pair, and MUST be responded to on the previously > >> validated pair, until ICE restart completes." > > Sure will make this change. > > > > Regards, > > Ram > > > >> Regards, Christian > >> > >> _______________________________________________ > >> 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 nobody Wed Oct 8 23:50:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48ED1A9113 for ; Wed, 8 Oct 2014 23:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkJgPi07Dfkc for ; Wed, 8 Oct 2014 23:50:14 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950F81A910F for ; Wed, 8 Oct 2014 23:50:14 -0700 (PDT) Received: from ppp118-209-249-5.lns20.mel8.internode.on.net ([118.209.249.5]:56684 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xc7Y3-0006AR-B1; Thu, 09 Oct 2014 17:50:03 +1100 Message-ID: <54363020.2040807@nteczone.com> Date: Thu, 09 Oct 2014 17:50:08 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" References: <5434B4D9.8000302@nteczone.com> <5435EC15.3040908@nteczone.com> <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> 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 - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sJs38P2ZBwPPIAcVvF6W3fK5FZk Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 06:50:16 -0000 Hello Tiru, So does this mean that the receiver also has to keep track of 30 second consent period to be able to identify the situation? Regards, Christian On 9/10/2014 5:42 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian >> Groves >> Sent: Thursday, October 09, 2014 7:30 AM >> To: Ram Mohan R (rmohanr); rtcweb@ietf.org >> Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness >> >> Hello Ram, >> >> Thanks for the response. A further question. The draft focuses on sender >> behaviour with regards to consent, i.e. it indicates that an endpoint must not >> send data if consent hasn't been granted. What about receiver behaviour? >> E.g. what happens if the sending end point is not well behaved and sends >> application data beyond the consent period, what should the receiver do ? > The receiver can use DTLS fatal error to immediately revoke the consent. But if sender does not care about consent revocation then the receiver has to rely on other techniques (like closing the FW mapping etc.). The javascript may be malicious, hence consent checks are done by the browser (which serves as user's TCB)) and browser has to be trusted to do the right thing. > > -Tiru > >> Regards, Christian >> >> On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote: >>> Hi Christian, >>> >>> Thanks for your comments. Please see inline >>> >>> -----Original Message----- >>> From: Christian Groves >>> Date: Wednesday, 8 October 2014 9:21 am >>> To: "rtcweb@ietf.org" >>> Subject: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness >>> >>>> Hello, >>>> >>>> I have a couple of comments on >>>> draft-ietf-rtcweb-stun-consent-freshness-07: >>>> >>>> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both >>>> "ICE binding requests" and "STUN binding requests". Is there a >>>> distinction between them? e.g. "ICE binding requests" refer to >>>> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request >>>> indicates a non-extended binding request as per RFC5389. >>> We will change it to STUN binding requests to keep it consistent with >>> the rest of the document. >>> >>>> 2) Just to confirm when Consent is first given. Is the 30sec consent >>>> period assumed after the initial ICE exchange? >>> Paragraph 4 in Section 4.1 has this text. Hope this is sufficient. >>> >>> "The initial Consent to send traffic is obtained by ICE. Consent >>> expires after 30 seconds." >>> >>> >>>> I found the second >>>> paragraph in cl.4.1 not so clear as it talks about subsequent consent >>>> before the initial consent in paragraph 5. I'd suggest modifying it >>>> along the lines of: >>>> "An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, >>>> DTLS), over any transport protocol (e.g., UDP, TCP) on an >>>> ICE-initiated connection unless the receiving endpoint consents to receive >> the data. >>>> Initial consent is granted as a result of a successful ICE >>>> connectivity check on a particular transport address. Consent expires >>>> after a fixed amount of time. As a result, subsequent consent MUST be >>>> obtained following the procedure described in this document. >>>> >>>> During ICE restart consent checks MUST continue to be sent on >>>> previously validated pair, and MUST be responded to on the previously >>>> validated pair, until ICE restart completes." >>> Sure will make this change. >>> >>> Regards, >>> Ram >>> >>>> Regards, Christian >>>> >>>> _______________________________________________ >>>> 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 nobody Wed Oct 8 23:58:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADE81A9133 for ; Wed, 8 Oct 2014 23:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPiJRk0-_Dzd for ; Wed, 8 Oct 2014 23:58:34 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE141A9117 for ; Wed, 8 Oct 2014 23:58:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1155E7C09ED; Thu, 9 Oct 2014 08:58:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19lRzdC2RCri; Thu, 9 Oct 2014 08:58:32 +0200 (CEST) Received: from [172.30.42.85] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id F0ADF7C09DD; Thu, 9 Oct 2014 08:58:31 +0200 (CEST) Message-ID: <54363216.3060700@alvestrand.no> Date: Thu, 09 Oct 2014 08:58:30 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Parthasarathi R , 'Christer Holmberg' , rtcweb@ietf.org References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> In-Reply-To: <006301cfe316$6d3c5590$47b500b0$@co.in> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sVnMdKkEyOZnBVps7-luzxVFetE Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 06:58:36 -0000 On 10/08/2014 06:39 PM, Parthasarathi R wrote: > Hi Harald, > > Please read inline. > > Thanks > Partha > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Tuesday, October 07, 2014 10:16 PM >> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org >> Subject: Re: [rtcweb] Definitions of WebRTC entities >> >> On 10/07/2014 06:21 PM, Parthasarathi R wrote: >>> Hi Christer, >>> >>> I have no issue with WebRTC User Agent, WebRTC device, WebRTC >> endpoint. >>> I have bit trouble with WebRTC compatible endpoint as a entity name >> as >>> 1) It may pass SRTP/data channel >> What do you mean by "pass"? That's a slippery term. > "relay" will be more appropriate term as mentioned in Sec 5 Para 2 of draft-alvestrand-rtcweb-gateways. > >>> 2) It is not required to be endpoint but it shall be middle box. >> What do you mean by "middle box"? Again, that term is slippery. > I intent to say that the entity which is between two endpoints and it does not end any media session itself. Here, The confusion is that WebRTC compatible endpoint which is not an endpoint but it is a middle box. Seems that this entity (whatever it's called) isn't an endpoint at all, so defining terms for endpoints shouldn't be relevant to whatever this device is. There's always more boxes in the middle..... although as long as they don't have the DTLS keys, it's limited what they can do to the packets. > >>> WebRTC gateway looks more appropriate entity name in those scenarios. >> As written in my proposal, a WebRTC gateway is a WebRTC compatible >> endpoint. >> > As per your proposal, we need to define WebRTC compatible endpoint first which is super set of WebRTC gateway. Then, we need to clarify which kind of WebRTC compatible endpoint qualify as WebRTC gateway. But Christer wishes to have only two definition (Full/Subset). And I don't agree with Christer, so then we're two :-) From nobody Thu Oct 9 00:01:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3121A9127 for ; Thu, 9 Oct 2014 00:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iioRJroIxW2P for ; Thu, 9 Oct 2014 00:00:58 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 552661A9117 for ; Thu, 9 Oct 2014 00:00:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 616577C09ED for ; Thu, 9 Oct 2014 09:00:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvO3YjidGyRK for ; Thu, 9 Oct 2014 09:00:56 +0200 (CEST) Received: from [172.30.42.85] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id F362E7C035F for ; Thu, 9 Oct 2014 09:00:55 +0200 (CEST) Message-ID: <543632A7.6050401@alvestrand.no> Date: Thu, 09 Oct 2014 09:00:55 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5434B4D9.8000302@nteczone.com> <5435EC15.3040908@nteczone.com> <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> <54363020.2040807@nteczone.com> In-Reply-To: <54363020.2040807@nteczone.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ri5-h_oXcFknmfD8ysSPmzeFXBk Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 07:01:00 -0000 On 10/09/2014 08:50 AM, Christian Groves wrote: > Hello Tiru, > > So does this mean that the receiver also has to keep track of 30 > second consent period to be able to identify the situation? If the receiver cares about being flooded without its consent, the receiver needs to detect that situation and take appropriate action. Either by watching the 30-second timer or by some other means. If the receiver doesn't care, it doesn't have to do anything. I don't think the spec needs to mandate any particular reaction from the receiver in this situation. > > Regards, Christian > > On 9/10/2014 5:42 PM, Tirumaleswar Reddy (tireddy) wrote: >>> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: Thursday, October 09, 2014 7:30 AM >>> To: Ram Mohan R (rmohanr); rtcweb@ietf.org >>> Subject: Re: [rtcweb] Question on >>> draft-ietf-rtcweb-stun-consent-freshness >>> >>> Hello Ram, >>> >>> Thanks for the response. A further question. The draft focuses on >>> sender >>> behaviour with regards to consent, i.e. it indicates that an >>> endpoint must not >>> send data if consent hasn't been granted. What about receiver >>> behaviour? >>> E.g. what happens if the sending end point is not well behaved and >>> sends >>> application data beyond the consent period, what should the receiver >>> do ? >> The receiver can use DTLS fatal error to immediately revoke the >> consent. But if sender does not care about consent revocation then >> the receiver has to rely on other techniques (like closing the FW >> mapping etc.). The javascript may be malicious, hence consent checks >> are done by the browser (which serves as user's TCB)) and browser has >> to be trusted to do the right thing. >> >> -Tiru >> >>> Regards, Christian >>> >>> On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote: >>>> Hi Christian, >>>> >>>> Thanks for your comments. Please see inline >>>> >>>> -----Original Message----- >>>> From: Christian Groves >>>> Date: Wednesday, 8 October 2014 9:21 am >>>> To: "rtcweb@ietf.org" >>>> Subject: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness >>>> >>>>> Hello, >>>>> >>>>> I have a couple of comments on >>>>> draft-ietf-rtcweb-stun-consent-freshness-07: >>>>> >>>>> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both >>>>> "ICE binding requests" and "STUN binding requests". Is there a >>>>> distinction between them? e.g. "ICE binding requests" refer to >>>>> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request >>>>> indicates a non-extended binding request as per RFC5389. >>>> We will change it to STUN binding requests to keep it consistent with >>>> the rest of the document. >>>> >>>>> 2) Just to confirm when Consent is first given. Is the 30sec consent >>>>> period assumed after the initial ICE exchange? >>>> Paragraph 4 in Section 4.1 has this text. Hope this is sufficient. >>>> >>>> "The initial Consent to send traffic is obtained by ICE. Consent >>>> expires after 30 seconds." >>>> >>>> >>>>> I found the second >>>>> paragraph in cl.4.1 not so clear as it talks about subsequent consent >>>>> before the initial consent in paragraph 5. I'd suggest modifying it >>>>> along the lines of: >>>>> "An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, >>>>> DTLS), over any transport protocol (e.g., UDP, TCP) on an >>>>> ICE-initiated connection unless the receiving endpoint consents to >>>>> receive >>> the data. >>>>> Initial consent is granted as a result of a successful ICE >>>>> connectivity check on a particular transport address. Consent expires >>>>> after a fixed amount of time. As a result, subsequent consent MUST be >>>>> obtained following the procedure described in this document. >>>>> >>>>> During ICE restart consent checks MUST continue to be sent on >>>>> previously validated pair, and MUST be responded to on the previously >>>>> validated pair, until ICE restart completes." >>>> Sure will make this change. >>>> >>>> Regards, >>>> Ram >>>> >>>>> Regards, Christian >>>>> >>>>> _______________________________________________ >>>>> 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 -- Surveillance is pervasive. Go Dark. From nobody Thu Oct 9 00:21:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0CE1A9122 for ; Thu, 9 Oct 2014 00:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89lVno8n8DNZ for ; Thu, 9 Oct 2014 00:21:30 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7551A0037 for ; Thu, 9 Oct 2014 00:21:30 -0700 (PDT) Received: from ppp118-209-249-5.lns20.mel8.internode.on.net ([118.209.249.5]:56910 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xc82J-0002A5-MH for rtcweb@ietf.org; Thu, 09 Oct 2014 18:21:19 +1100 Message-ID: <54363775.40108@nteczone.com> Date: Thu, 09 Oct 2014 18:21:25 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5434B4D9.8000302@nteczone.com> <5435EC15.3040908@nteczone.com> <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> <54363020.2040807@nteczone.com> <543632A7.6050401@alvestrand.no> In-Reply-To: <543632A7.6050401@alvestrand.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 - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t5TQgqb_YiMPMEoOclm7Cx8pkLk Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 07:21:33 -0000 I don't think it should mandate a particular action but I think it would be good to mention some of the possibilities. As it stands nothing is mentioned in the draft about the role of the receiver. If the receiver watches the 30 second timer, how does it distinguish between receiving a STUN binding request for the purposes of Consent (i.e. linked to application data signalling) and a STUN binding request sent for the purposes of a keep alive? I guess that it uses the fact that consent related STUN binding request are authenticated and keepalive STUN binding requests are not (as per cl.10/RFC5245. Is that correct? Regards, Christian On 9/10/2014 6:00 PM, Harald Alvestrand wrote: > On 10/09/2014 08:50 AM, Christian Groves wrote: >> Hello Tiru, >> >> So does this mean that the receiver also has to keep track of 30 >> second consent period to be able to identify the situation? > If the receiver cares about being flooded without its consent, the > receiver needs to detect that situation and take appropriate action. > Either by watching the 30-second timer or by some other means. > > If the receiver doesn't care, it doesn't have to do anything. > > I don't think the spec needs to mandate any particular reaction from the > receiver in this situation. > > > > >> Regards, Christian >> >> On 9/10/2014 5:42 PM, Tirumaleswar Reddy (tireddy) wrote: >>>> -----Original Message----- >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian >>>> Groves >>>> Sent: Thursday, October 09, 2014 7:30 AM >>>> To: Ram Mohan R (rmohanr); rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Question on >>>> draft-ietf-rtcweb-stun-consent-freshness >>>> >>>> Hello Ram, >>>> >>>> Thanks for the response. A further question. The draft focuses on >>>> sender >>>> behaviour with regards to consent, i.e. it indicates that an >>>> endpoint must not >>>> send data if consent hasn't been granted. What about receiver >>>> behaviour? >>>> E.g. what happens if the sending end point is not well behaved and >>>> sends >>>> application data beyond the consent period, what should the receiver >>>> do ? >>> The receiver can use DTLS fatal error to immediately revoke the >>> consent. But if sender does not care about consent revocation then >>> the receiver has to rely on other techniques (like closing the FW >>> mapping etc.). The javascript may be malicious, hence consent checks >>> are done by the browser (which serves as user's TCB)) and browser has >>> to be trusted to do the right thing. >>> >>> -Tiru >>> >>>> Regards, Christian >>>> >>>> On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote: >>>>> Hi Christian, >>>>> >>>>> Thanks for your comments. Please see inline >>>>> >>>>> -----Original Message----- >>>>> From: Christian Groves >>>>> Date: Wednesday, 8 October 2014 9:21 am >>>>> To: "rtcweb@ietf.org" >>>>> Subject: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness >>>>> >>>>>> Hello, >>>>>> >>>>>> I have a couple of comments on >>>>>> draft-ietf-rtcweb-stun-consent-freshness-07: >>>>>> >>>>>> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both >>>>>> "ICE binding requests" and "STUN binding requests". Is there a >>>>>> distinction between them? e.g. "ICE binding requests" refer to >>>>>> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request >>>>>> indicates a non-extended binding request as per RFC5389. >>>>> We will change it to STUN binding requests to keep it consistent with >>>>> the rest of the document. >>>>> >>>>>> 2) Just to confirm when Consent is first given. Is the 30sec consent >>>>>> period assumed after the initial ICE exchange? >>>>> Paragraph 4 in Section 4.1 has this text. Hope this is sufficient. >>>>> >>>>> "The initial Consent to send traffic is obtained by ICE. Consent >>>>> expires after 30 seconds." >>>>> >>>>> >>>>>> I found the second >>>>>> paragraph in cl.4.1 not so clear as it talks about subsequent consent >>>>>> before the initial consent in paragraph 5. I'd suggest modifying it >>>>>> along the lines of: >>>>>> "An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, >>>>>> DTLS), over any transport protocol (e.g., UDP, TCP) on an >>>>>> ICE-initiated connection unless the receiving endpoint consents to >>>>>> receive >>>> the data. >>>>>> Initial consent is granted as a result of a successful ICE >>>>>> connectivity check on a particular transport address. Consent expires >>>>>> after a fixed amount of time. As a result, subsequent consent MUST be >>>>>> obtained following the procedure described in this document. >>>>>> >>>>>> During ICE restart consent checks MUST continue to be sent on >>>>>> previously validated pair, and MUST be responded to on the previously >>>>>> validated pair, until ICE restart completes." >>>>> Sure will make this change. >>>>> >>>>> Regards, >>>>> Ram >>>>> >>>>>> Regards, Christian >>>>>> >>>>>> _______________________________________________ >>>>>> 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 nobody Thu Oct 9 01:29:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EECD1ACCE2 for ; Thu, 9 Oct 2014 01:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.686 X-Spam-Level: X-Spam-Status: No, score=-7.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKqciA23Eutf for ; Thu, 9 Oct 2014 01:28:59 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAE41A0222 for ; Thu, 9 Oct 2014 01:28:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEMANhGNlSHCzIm/2dsb2JhbABfgmsjU1gEuAoGkwIiDIZ3VAKBBxYBAXEJhAMBAQEBAwEBAQ8oNBcEAgEIDQQEAQELFAkHJwsUBwEBBQMCBBMIGogcAQymTp8cAReGIIlzOAaDJ4EeBZF3hD6IPjyDCYMajgCDY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,683,1406606400"; d="scan'208";a="75541500" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Oct 2014 04:28:55 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 09 Oct 2014 04:28:54 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 10:28:53 +0200 From: "Romascanu, Dan (Dan)" To: "rtcweb@ietf.org" Thread-Topic: [xrblock] I-D Action: draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-00.txt Thread-Index: AQHP45rGqwvfg5sL90a4fZCTNDCC5Jwnbnhg Date: Thu, 9 Oct 2014 08:28:52 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8C4C0B@AZ-FFEXMB04.global.avaya.com> References: <20141009082639.2805.55580.idtracker@ietfa.amsl.com> In-Reply-To: <20141009082639.2805.55580.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DuYH8n0ItwIs16t8HPjr19W2n6o Subject: [rtcweb] FW: [xrblock] I-D Action: draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 08:29:01 -0000 FYI - this Internet-Draft was submitted in the XRBLOCK WG.=20 Comments are welcome.=20 Regards, Dan > -----Original Message----- > From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, October 09, 2014 11:27 AM > To: i-d-announce@ietf.org > Cc: xrblock@ietf.org > Subject: [xrblock] I-D Action: draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-= 00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Metric Blocks for use with RTCP's Exten= ded > Report Framework Working Group of the IETF. >=20 > Title : Considerations for Selecting RTCP Extended Repo= rt (XR) > Metrics for the RTCWEB Statistics API > Authors : Rachel Huang > Roni Even > Varun Singh > Dan Romascanu > Lingli Deng > Filename : draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-00.txt > Pages : 15 > Date : 2014-10-08 >=20 > Abstract: > This document describes monitoring features related to RTCWEB. It > provides a list of RTCP XR metrics, which are useful and may need to > be supported in some RTCWEB implementations. It also describes a > list of additional identifiers for WebRTC's statistics API. These > identifiers are a set of RTCP XR metrics related to the transport of > multimedia flows. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcweb-rtcp-xr-metric= s/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock From nobody Thu Oct 9 01:29:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3C71A0222 for ; Thu, 9 Oct 2014 01:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNJofkI9mV90 for ; Thu, 9 Oct 2014 01:29:32 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E7F1A00A6 for ; Thu, 9 Oct 2014 01:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6417; q=dns/txt; s=iport; t=1412843371; x=1414052971; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TBBSr7um1511fPTE3hdmLupCAQTQtfIp98kW6qgqzwI=; b=Gb1RLovHdmrlE/N3LqYrL7R9Qfc3OUWiIQZlvR87stzWRgtUv0kNKkhX 80dsuhh4rfh+QnlY8P0Td5MB1hj3S5SAEUx2881kiNgLej45A9+boA6zu i2CuTHokkfJM2FQHmmSx8ExFkf8ZM0ZHfgJpzuTAWLqVydkQYDJMDoxZ0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAPFFNlStJA2F/2dsb2JhbABVCoMOU1gEyzQMhndUAoEHFgF7hAMBAQEDAQEBATc0FwQCAQgRAwEBAQEKFAkHJwsUCQgCBAESCIguCA3FZAEXj2grBjIGgyeBHgWRd4Q+iD48gwmNG4N/g2NsAYEFAh4CBByBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,683,1406592000"; d="scan'208";a="85346207" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 09 Oct 2014 08:29:30 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s998TUC6024505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 08:29:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 03:29:29 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Christian Groves , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHP4qtCUX66zMXLWE+lLN2cNcLkkJwmFCwAgAFDuYD///etwIAAWXAAgAADA4CAAAW6gP//vepA Date: Thu, 9 Oct 2014 08:29:29 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28338614@xmb-rcd-x10.cisco.com> References: <5434B4D9.8000302@nteczone.com> <5435EC15.3040908@nteczone.com> <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> <54363020.2040807@nteczone.com> <543632A7.6050401@alvestrand.no> <54363775.40108@nteczone.com> In-Reply-To: <54363775.40108@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.76.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wLjqHau4SALExiFlIam8RfRPGMk Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 08:29:34 -0000 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian > Groves > Sent: Thursday, October 09, 2014 12:51 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshnes= s >=20 > I don't think it should mandate a particular action but I think it would = be > good to mention some of the possibilities. As it stands nothing is mentio= ned > in the draft about the role of the receiver. The role of receiver to immediately revoke consent either using STUN error = code or DTLS fatal alert is discussed in =20 http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-07#sect= ion-4.2 -Tiru >=20 > If the receiver watches the 30 second timer, how does it distinguish betw= een > receiving a STUN binding request for the purposes of Consent (i.e. linked= to > application data signalling) and a STUN binding request sent for the purp= oses > of a keep alive? I guess that it uses the fact that consent related STUN = binding > request are authenticated and keepalive STUN binding requests are not (as > per cl.10/RFC5245. Is that correct? >=20 > Regards, Christian >=20 > On 9/10/2014 6:00 PM, Harald Alvestrand wrote: > > On 10/09/2014 08:50 AM, Christian Groves wrote: > >> Hello Tiru, > >> > >> So does this mean that the receiver also has to keep track of 30 > >> second consent period to be able to identify the situation? > > If the receiver cares about being flooded without its consent, the > > receiver needs to detect that situation and take appropriate action. > > Either by watching the 30-second timer or by some other means. > > > > If the receiver doesn't care, it doesn't have to do anything. > > > > I don't think the spec needs to mandate any particular reaction from > > the receiver in this situation. > > > > > > > > > >> Regards, Christian > >> > >> On 9/10/2014 5:42 PM, Tirumaleswar Reddy (tireddy) wrote: > >>>> -----Original Message----- > >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > >>>> Christian Groves > >>>> Sent: Thursday, October 09, 2014 7:30 AM > >>>> To: Ram Mohan R (rmohanr); rtcweb@ietf.org > >>>> Subject: Re: [rtcweb] Question on > >>>> draft-ietf-rtcweb-stun-consent-freshness > >>>> > >>>> Hello Ram, > >>>> > >>>> Thanks for the response. A further question. The draft focuses on > >>>> sender behaviour with regards to consent, i.e. it indicates that an > >>>> endpoint must not send data if consent hasn't been granted. What > >>>> about receiver behaviour? > >>>> E.g. what happens if the sending end point is not well behaved and > >>>> sends application data beyond the consent period, what should the > >>>> receiver do ? > >>> The receiver can use DTLS fatal error to immediately revoke the > >>> consent. But if sender does not care about consent revocation then > >>> the receiver has to rely on other techniques (like closing the FW > >>> mapping etc.). The javascript may be malicious, hence consent > >>> checks are done by the browser (which serves as user's TCB)) and > >>> browser has to be trusted to do the right thing. > >>> > >>> -Tiru > >>> > >>>> Regards, Christian > >>>> > >>>> On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote: > >>>>> Hi Christian, > >>>>> > >>>>> Thanks for your comments. Please see inline > >>>>> > >>>>> -----Original Message----- > >>>>> From: Christian Groves > >>>>> Date: Wednesday, 8 October 2014 9:21 am > >>>>> To: "rtcweb@ietf.org" > >>>>> Subject: [rtcweb] Question on > >>>>> draft-ietf-rtcweb-stun-consent-freshness > >>>>> > >>>>>> Hello, > >>>>>> > >>>>>> I have a couple of comments on > >>>>>> draft-ietf-rtcweb-stun-consent-freshness-07: > >>>>>> > >>>>>> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both > >>>>>> "ICE binding requests" and "STUN binding requests". Is there a > >>>>>> distinction between them? e.g. "ICE binding requests" refer to > >>>>>> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request > >>>>>> indicates a non-extended binding request as per RFC5389. > >>>>> We will change it to STUN binding requests to keep it consistent > >>>>> with the rest of the document. > >>>>> > >>>>>> 2) Just to confirm when Consent is first given. Is the 30sec > >>>>>> consent period assumed after the initial ICE exchange? > >>>>> Paragraph 4 in Section 4.1 has this text. Hope this is sufficient. > >>>>> > >>>>> "The initial Consent to send traffic is obtained by ICE. Consent > >>>>> expires after 30 seconds." > >>>>> > >>>>> > >>>>>> I found the second > >>>>>> paragraph in cl.4.1 not so clear as it talks about subsequent > >>>>>> consent before the initial consent in paragraph 5. I'd suggest > >>>>>> modifying it along the lines of: > >>>>>> "An endpoint MUST NOT send application data (e.g., RTP, RTCP, > >>>>>> SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) on an > >>>>>> ICE-initiated connection unless the receiving endpoint consents > >>>>>> to receive > >>>> the data. > >>>>>> Initial consent is granted as a result of a successful ICE > >>>>>> connectivity check on a particular transport address. Consent > >>>>>> expires after a fixed amount of time. As a result, subsequent > >>>>>> consent MUST be obtained following the procedure described in this > document. > >>>>>> > >>>>>> During ICE restart consent checks MUST continue to be sent on > >>>>>> previously validated pair, and MUST be responded to on the > >>>>>> previously validated pair, until ICE restart completes." > >>>>> Sure will make this change. > >>>>> > >>>>> Regards, > >>>>> Ram > >>>>> > >>>>>> Regards, Christian > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Oct 9 02:49:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BDD1A0101 for ; Thu, 9 Oct 2014 02:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86Hzlj52OUyj for ; Thu, 9 Oct 2014 02:49:37 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635BF1ACD18 for ; Thu, 9 Oct 2014 02:49:37 -0700 (PDT) Received: from ppp118-209-249-5.lns20.mel8.internode.on.net ([118.209.249.5]:59535 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XcALc-0005WG-Le; Thu, 09 Oct 2014 20:49:24 +1100 Message-ID: <54365A2B.9080007@nteczone.com> Date: Thu, 09 Oct 2014 20:49:31 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "rtcweb@ietf.org" References: <5434B4D9.8000302@nteczone.com> <5435EC15.3040908@nteczone.com> <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> <54363020.2040807@nteczone.com> <543632A7.6050401@alvestrand.no> <54363775.40108@nteczone.com> <913383AAA69FF945B8F946018B75898A28338614@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A28338614@xmb-rcd-x10.cisco.com> 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 - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6tSNzOCt3DoMp0lUrIk_VgZMwrQ Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 09:49:40 -0000 Hello Tiru, I've seen that text but it talks about the receiving endpoint of a STUN binding response. I was referring to the endpoint that receives the STUN binding request and sends the response. The draft concentrates on the STUN binding request initiator and its notion of consent. It doesn't explain what notion of consent that the receiver of the STUN binding request. E.g. a STUN binding request receiver may close the connection which leads to an immediate revokation but it doesn't mean it has the notion of consent. As Harald indicates below the receiver may not care at all about it. Regards, Christian On 9/10/2014 7:29 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian >> Groves >> Sent: Thursday, October 09, 2014 12:51 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness >> >> I don't think it should mandate a particular action but I think it would be >> good to mention some of the possibilities. As it stands nothing is mentioned >> in the draft about the role of the receiver. > The role of receiver to immediately revoke consent either using STUN error code or DTLS fatal alert is discussed in > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-07#section-4.2 > > -Tiru > >> If the receiver watches the 30 second timer, how does it distinguish between >> receiving a STUN binding request for the purposes of Consent (i.e. linked to >> application data signalling) and a STUN binding request sent for the purposes >> of a keep alive? I guess that it uses the fact that consent related STUN binding >> request are authenticated and keepalive STUN binding requests are not (as >> per cl.10/RFC5245. Is that correct? >> >> Regards, Christian >> >> On 9/10/2014 6:00 PM, Harald Alvestrand wrote: >>> On 10/09/2014 08:50 AM, Christian Groves wrote: >>>> Hello Tiru, >>>> >>>> So does this mean that the receiver also has to keep track of 30 >>>> second consent period to be able to identify the situation? >>> If the receiver cares about being flooded without its consent, the >>> receiver needs to detect that situation and take appropriate action. >>> Either by watching the 30-second timer or by some other means. >>> >>> If the receiver doesn't care, it doesn't have to do anything. >>> >>> I don't think the spec needs to mandate any particular reaction from >>> the receiver in this situation. >>> >>> >>> >>> >>>> Regards, Christian >>>> >>>> On 9/10/2014 5:42 PM, Tirumaleswar Reddy (tireddy) wrote: >>>>>> -----Original Message----- >>>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of >>>>>> Christian Groves >>>>>> Sent: Thursday, October 09, 2014 7:30 AM >>>>>> To: Ram Mohan R (rmohanr); rtcweb@ietf.org >>>>>> Subject: Re: [rtcweb] Question on >>>>>> draft-ietf-rtcweb-stun-consent-freshness >>>>>> >>>>>> Hello Ram, >>>>>> >>>>>> Thanks for the response. A further question. The draft focuses on >>>>>> sender behaviour with regards to consent, i.e. it indicates that an >>>>>> endpoint must not send data if consent hasn't been granted. What >>>>>> about receiver behaviour? >>>>>> E.g. what happens if the sending end point is not well behaved and >>>>>> sends application data beyond the consent period, what should the >>>>>> receiver do ? >>>>> The receiver can use DTLS fatal error to immediately revoke the >>>>> consent. But if sender does not care about consent revocation then >>>>> the receiver has to rely on other techniques (like closing the FW >>>>> mapping etc.). The javascript may be malicious, hence consent >>>>> checks are done by the browser (which serves as user's TCB)) and >>>>> browser has to be trusted to do the right thing. >>>>> >>>>> -Tiru >>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote: >>>>>>> Hi Christian, >>>>>>> >>>>>>> Thanks for your comments. Please see inline >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Christian Groves >>>>>>> Date: Wednesday, 8 October 2014 9:21 am >>>>>>> To: "rtcweb@ietf.org" >>>>>>> Subject: [rtcweb] Question on >>>>>>> draft-ietf-rtcweb-stun-consent-freshness >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have a couple of comments on >>>>>>>> draft-ietf-rtcweb-stun-consent-freshness-07: >>>>>>>> >>>>>>>> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both >>>>>>>> "ICE binding requests" and "STUN binding requests". Is there a >>>>>>>> distinction between them? e.g. "ICE binding requests" refer to >>>>>>>> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request >>>>>>>> indicates a non-extended binding request as per RFC5389. >>>>>>> We will change it to STUN binding requests to keep it consistent >>>>>>> with the rest of the document. >>>>>>> >>>>>>>> 2) Just to confirm when Consent is first given. Is the 30sec >>>>>>>> consent period assumed after the initial ICE exchange? >>>>>>> Paragraph 4 in Section 4.1 has this text. Hope this is sufficient. >>>>>>> >>>>>>> "The initial Consent to send traffic is obtained by ICE. Consent >>>>>>> expires after 30 seconds." >>>>>>> >>>>>>> >>>>>>>> I found the second >>>>>>>> paragraph in cl.4.1 not so clear as it talks about subsequent >>>>>>>> consent before the initial consent in paragraph 5. I'd suggest >>>>>>>> modifying it along the lines of: >>>>>>>> "An endpoint MUST NOT send application data (e.g., RTP, RTCP, >>>>>>>> SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) on an >>>>>>>> ICE-initiated connection unless the receiving endpoint consents >>>>>>>> to receive >>>>>> the data. >>>>>>>> Initial consent is granted as a result of a successful ICE >>>>>>>> connectivity check on a particular transport address. Consent >>>>>>>> expires after a fixed amount of time. As a result, subsequent >>>>>>>> consent MUST be obtained following the procedure described in this >> document. >>>>>>>> During ICE restart consent checks MUST continue to be sent on >>>>>>>> previously validated pair, and MUST be responded to on the >>>>>>>> previously validated pair, until ICE restart completes." >>>>>>> Sure will make this change. >>>>>>> >>>>>>> Regards, >>>>>>> Ram >>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 nobody Thu Oct 9 05:18:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513641ACE19 for ; Thu, 9 Oct 2014 05:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6PxYStLjnae for ; Thu, 9 Oct 2014 05:18:43 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9A91ACE17 for ; Thu, 9 Oct 2014 05:18:42 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-0c-54367d2083b1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 50.64.24955.02D76345; Thu, 9 Oct 2014 14:18:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 14:18:39 +0200 From: Christer Holmberg To: Christian Groves , "Tirumaleswar Reddy (tireddy)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHP4qs779XvQTuAckOJ6nYUBAmKIJwlntMAgAFDuYCAAE8WgIAAAgcAgAADA4CAAAW7gIAAEwSAgAAWXYCAAEpxgA== Date: Thu, 9 Oct 2014 12:18:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47093C@ESESSMB209.ericsson.se> References: <5434B4D9.8000302@nteczone.com> <5435EC15.3040908@nteczone.com> <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> <54363020.2040807@nteczone.com> <543632A7.6050401@alvestrand.no> <54363775.40108@nteczone.com> <913383AAA69FF945B8F946018B75898A28338614@xmb-rcd-x10.cisco.com> <54365A2B.9080007@nteczone.com> In-Reply-To: <54365A2B.9080007@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja5CrVmIwcY30hZf3jeyWKz9185u cWL3NkYHZo8pvzeyeixZ8pPJY8X5mSwBzFFcNimpOZllqUX6dglcGRs2LGUquGhb8bLVq4Hx gHEXIyeHhICJxI7lX1ggbDGJC/fWs3UxcnEICRxllNj4YDszhLOYUeL69EYgh4ODTcBCovuf NkhcRKCfUeLOxEvMIN3CAl4SE26fA7NFBLwl1s7bxg5hZ0lMWPoFLM4ioCLRNfkBWJxXwFfi 2aNJ7BALfjNJXL1yBuwMTgEdiYsbToA1MAKd9P3UGiYQm1lAXOLWk/lMEKcKSCzZc54ZwhaV ePn4HyuErSjx8dU+Roh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjKKzkIydhaRlFpKWWUha FjCyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjJ6DW36r7mC8/MbxEKMAB6MSD2+CilmI EGtiWXFl7iFGaQ4WJXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgVBCc9lP2X8lT uRmpV17eevZxpojJGS9x45NC2156Zz/4oO+n+fDVvgmKvzs6FogkbH4v3FLdqWH48qdG/t8n U3usC95dntT2XILzeoFv0iqNs7oGalxSszO21JW7/tfn6deOS+wMnKgmqv+PVcHh1uQY01O6 i7MY9YX2z/w34058hp5p2J5wJZbijERDLeai4kQAy3mPan8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/z11nvAMIBP2o_qEhkjyOv_uLGC0 Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 12:18:46 -0000 Hi, Why would the receiver have to do anything? Each endpoint uses consent chec= ks to verify that it can SEND media. Also, keep in mind that if the remote peer is ICE lite, it won't send any c= onsent checks. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian Groves Sent: 9. lokakuuta 2014 12:50 To: Tirumaleswar Reddy (tireddy); rtcweb@ietf.org Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness Hello Tiru, I've seen that text but it talks about the receiving endpoint of a STUN bin= ding response. I was referring to the endpoint that receives the STUN bindi= ng request and sends the response. The draft concentrates on the STUN bindi= ng request initiator and its notion of consent. It doesn't explain what not= ion of consent that the receiver of the STUN binding request. E.g. a STUN b= inding request receiver may close the connection which leads to an immediat= e revokation but it doesn't mean it has the notion of consent. As Harald in= dicates below the receiver may not care at all about it. Regards, Christian On 9/10/2014 7:29 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian=20 >> Groves >> Sent: Thursday, October 09, 2014 12:51 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Question on=20 >> draft-ietf-rtcweb-stun-consent-freshness >> >> I don't think it should mandate a particular action but I think it=20 >> would be good to mention some of the possibilities. As it stands=20 >> nothing is mentioned in the draft about the role of the receiver. > The role of receiver to immediately revoke consent either using STUN=20 > error code or DTLS fatal alert is discussed in > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-07 > #section-4.2 > > -Tiru > >> If the receiver watches the 30 second timer, how does it distinguish=20 >> between receiving a STUN binding request for the purposes of Consent=20 >> (i.e. linked to application data signalling) and a STUN binding=20 >> request sent for the purposes of a keep alive? I guess that it uses=20 >> the fact that consent related STUN binding request are authenticated=20 >> and keepalive STUN binding requests are not (as per cl.10/RFC5245. Is th= at correct? >> >> Regards, Christian >> >> On 9/10/2014 6:00 PM, Harald Alvestrand wrote: >>> On 10/09/2014 08:50 AM, Christian Groves wrote: >>>> Hello Tiru, >>>> >>>> So does this mean that the receiver also has to keep track of 30=20 >>>> second consent period to be able to identify the situation? >>> If the receiver cares about being flooded without its consent, the=20 >>> receiver needs to detect that situation and take appropriate action. >>> Either by watching the 30-second timer or by some other means. >>> >>> If the receiver doesn't care, it doesn't have to do anything. >>> >>> I don't think the spec needs to mandate any particular reaction from=20 >>> the receiver in this situation. >>> >>> >>> >>> >>>> Regards, Christian >>>> >>>> On 9/10/2014 5:42 PM, Tirumaleswar Reddy (tireddy) wrote: >>>>>> -----Original Message----- >>>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 >>>>>> Christian Groves >>>>>> Sent: Thursday, October 09, 2014 7:30 AM >>>>>> To: Ram Mohan R (rmohanr); rtcweb@ietf.org >>>>>> Subject: Re: [rtcweb] Question on=20 >>>>>> draft-ietf-rtcweb-stun-consent-freshness >>>>>> >>>>>> Hello Ram, >>>>>> >>>>>> Thanks for the response. A further question. The draft focuses on=20 >>>>>> sender behaviour with regards to consent, i.e. it indicates that=20 >>>>>> an endpoint must not send data if consent hasn't been granted.=20 >>>>>> What about receiver behaviour? >>>>>> E.g. what happens if the sending end point is not well behaved=20 >>>>>> and sends application data beyond the consent period, what should=20 >>>>>> the receiver do ? >>>>> The receiver can use DTLS fatal error to immediately revoke the=20 >>>>> consent. But if sender does not care about consent revocation then=20 >>>>> the receiver has to rely on other techniques (like closing the FW=20 >>>>> mapping etc.). The javascript may be malicious, hence consent=20 >>>>> checks are done by the browser (which serves as user's TCB)) and=20 >>>>> browser has to be trusted to do the right thing. >>>>> >>>>> -Tiru >>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote: >>>>>>> Hi Christian, >>>>>>> >>>>>>> Thanks for your comments. Please see inline >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Christian Groves >>>>>>> Date: Wednesday, 8 October 2014 9:21 am >>>>>>> To: "rtcweb@ietf.org" >>>>>>> Subject: [rtcweb] Question on >>>>>>> draft-ietf-rtcweb-stun-consent-freshness >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have a couple of comments on >>>>>>>> draft-ietf-rtcweb-stun-consent-freshness-07: >>>>>>>> >>>>>>>> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to=20 >>>>>>>> both "ICE binding requests" and "STUN binding requests". Is=20 >>>>>>>> there a distinction between them? e.g. "ICE binding requests"=20 >>>>>>>> refer to >>>>>>>> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request=20 >>>>>>>> indicates a non-extended binding request as per RFC5389. >>>>>>> We will change it to STUN binding requests to keep it consistent=20 >>>>>>> with the rest of the document. >>>>>>> >>>>>>>> 2) Just to confirm when Consent is first given. Is the 30sec=20 >>>>>>>> consent period assumed after the initial ICE exchange? >>>>>>> Paragraph 4 in Section 4.1 has this text. Hope this is sufficient. >>>>>>> >>>>>>> "The initial Consent to send traffic is obtained by ICE. Consent >>>>>>> expires after 30 seconds." >>>>>>> >>>>>>> >>>>>>>> I found the second >>>>>>>> paragraph in cl.4.1 not so clear as it talks about subsequent=20 >>>>>>>> consent before the initial consent in paragraph 5. I'd suggest=20 >>>>>>>> modifying it along the lines of: >>>>>>>> "An endpoint MUST NOT send application data (e.g., RTP, RTCP,=20 >>>>>>>> SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) on an=20 >>>>>>>> ICE-initiated connection unless the receiving endpoint consents=20 >>>>>>>> to receive >>>>>> the data. >>>>>>>> Initial consent is granted as a result of a successful ICE=20 >>>>>>>> connectivity check on a particular transport address. Consent=20 >>>>>>>> expires after a fixed amount of time. As a result, subsequent=20 >>>>>>>> consent MUST be obtained following the procedure described in=20 >>>>>>>> this >> document. >>>>>>>> During ICE restart consent checks MUST continue to be sent on=20 >>>>>>>> previously validated pair, and MUST be responded to on the=20 >>>>>>>> previously validated pair, until ICE restart completes." >>>>>>> Sure will make this change. >>>>>>> >>>>>>> Regards, >>>>>>> Ram >>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 nobody Thu Oct 9 06:36:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EF41A1A10 for ; Thu, 9 Oct 2014 06:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0O-WS_BE9dZ for ; Thu, 9 Oct 2014 06:36:03 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACE01ACEA3 for ; Thu, 9 Oct 2014 06:35:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 97B767C0C57 for ; Thu, 9 Oct 2014 15:35:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQREougMBOC2 for ; Thu, 9 Oct 2014 15:35:48 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:9cf4:f511:86e4:c280]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8FD8E7C0C12 for ; Thu, 9 Oct 2014 15:35:48 +0200 (CEST) Message-ID: <54368F34.3030001@alvestrand.no> Date: Thu, 09 Oct 2014 15:35:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5434B4D9.8000302@nteczone.com> <5435EC15.3040908@nteczone.com> <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> <54363020.2040807@nteczone.com> <543632A7.6050401@alvestrand.no> <54363775.40108@nteczone.com> <913383AAA69FF945B8F946018B75898A28338614@xmb-rcd-x10.cisco.com> <54365A2B.9080007@nteczone.com> In-Reply-To: <54365A2B.9080007@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GVvtcizj3yJJ_MD6i8OtTs7LxeM Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 13:36:11 -0000 On 10/09/2014 11:49 AM, Christian Groves wrote: > Hello Tiru, > > I've seen that text but it talks about the receiving endpoint of a > STUN binding response. I was referring to the endpoint that receives > the STUN binding request and sends the response. Aha - I was thinking that the "receiver" was the media receiver (the one who cares whether he's being DOSed or not), you were talking about the receiver of the STUN binding request. > The draft concentrates on the STUN binding request initiator and its > notion of consent. It doesn't explain what notion of consent that the > receiver of the STUN binding request. I think that's simple. The receiver of the STUN binding request has no business trying to figure out why it got a binding request. Its business is to answer it. It's the initiator who knows why the request was sent. From nobody Thu Oct 9 12:08:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08CB1A1AD8 for ; Thu, 9 Oct 2014 12:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPbLdNBprS3X for ; Thu, 9 Oct 2014 12:08:11 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294771A0324 for ; Thu, 9 Oct 2014 12:08:11 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7877950A88; Thu, 9 Oct 2014 15:08:07 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Oct 2014 13:08:04 -0600 Message-Id: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EpO8KFn6b_m-RZz0Nryi5jZ32GE Subject: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 19:08:14 -0000 Once again, the chairs are updating dates for documents. I'm forming a = list of when we hope to have an RFC for various drafts. In many ways the = relative ordering of when these drafts is probably more accurate than = the actually dates. The straw man for dates is I-D.ietf-rtcweb-alpn 2015 Feb=20 I-D.ietf-rtcweb-audio 2015 May I-D.ietf-rtcweb-constraints-registry 2015 Jan=20 I-D.ietf-rtcweb-data-channel 2014 Dec I-D.ietf-rtcweb-data-protocol 2014 Dec I-D.ietf-rtcweb-jsep 2015 May=20 I-D.ietf-rtcweb-overview 2015 May=20 I-D.ietf-rtcweb-rtp-usage 2015 Jan I-D.ietf-rtcweb-security-arch 2015 Dec=20 I-D.ietf-rtcweb-security 2015 Dec=20 I-D.ietf-rtcweb-stun-consent-freshness 2015 Feb I-D.ietf-rtcweb-transports 2015 Jan I-D.ietf-rtcweb-video 2015 May If you are an author or involved with these drafts or just have a strong = opinion on what the date to be an RFC will be and want to use a = different date than the ones above, let me know. Thanks, Cullen If you are interested, I have a document where I track the dates of most = the normative dependencies for WebRTC at=20 https://tools.ietf.org/html/draft-jennings-rtcweb-deps From nobody Thu Oct 9 13:01:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057661A1A4C for ; Thu, 9 Oct 2014 13:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7S4-IRqAGw0 for ; Thu, 9 Oct 2014 13:00:58 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3F41A1A3F for ; Thu, 9 Oct 2014 13:00:57 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so1821192lbi.8 for ; Thu, 09 Oct 2014 13:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wHT8KfqsXftCpr1Ga6mfDkHTgD15NB2jgs61uuKAkos=; b=NHBzGnvBTQwUOIhoMN9BeH4DD8kITWC+hTkkPcz25+XJDm/XlD9ansA/kJa8OtO+2P KutHckGoSsiVusa0kQv0zUVyEZuh8v/W2EsKHSdpGmwTxnl0J3ZH0lfa/+akC5S4Wa+q Xln2fDwEEfvIu3B+Lw8Y8IDIy76Qt3N75Xl4qBcoLOUEOcH+KcImou4r8DVJag3r5FEg cp1+W40ekdo28wRljiV+yy2UNWg3xMGPaZWjI5qm6NsdE62rx7Xwk/O4BXuUHLe9ihOR 7RFh5Rt5sCDCmDsi9HKGpbaE2CSKm8vjpaQySSCoznI3LEjL/1sSFhcqSIuS2GPcDspc V+OA== MIME-Version: 1.0 X-Received: by 10.152.3.167 with SMTP id d7mr8421981lad.17.1412884855916; Thu, 09 Oct 2014 13:00:55 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Thu, 9 Oct 2014 13:00:55 -0700 (PDT) In-Reply-To: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> Date: Thu, 9 Oct 2014 13:00:55 -0700 Message-ID: From: Martin Thomson To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ASzzBDo-qs6EdIk3Qgr3qtudSHQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 20:01:00 -0000 On 9 October 2014 12:08, Cullen Jennings wrote: > I-D.ietf-rtcweb-jsep 2015 May https://www.youtube.com/watch?v=dik_wnOE4dk&index=2&t=33s&list=WL This is a really large document and a good proportion of it hasn't been reviewed or discussed. From nobody Thu Oct 9 13:19:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391781A6EFC for ; Thu, 9 Oct 2014 13:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbgUgID1V2xY for ; Thu, 9 Oct 2014 13:19:26 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7E51A1BD9 for ; Thu, 9 Oct 2014 13:19:25 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so68457wib.11 for ; Thu, 09 Oct 2014 13:19:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TKIRvHcPRxaOQm0k2saTxf5Dd3AbOAPrmamppCIpj+0=; b=IPweA0CuISt/F+HMQOWUiSNemC1V0NF/CvAUY3uTsdv4PIaVJNbAZOElqdCVHWT+B6 cGXztGwOYT2kSXDmpPWGDiYUzxJ4+sSF+3O8aJgK6pJtrDTEVpoTFHDpzQqzY5cppRuo +ow/o0bjB2NBmnjJLRSQ2URLkwSbootvEG0KAxWwb0BOrc8bzQa1+/AmDjY1+jykwrmP PnWEqPCOl5687ZWCPNSkbgJr1qA+uNrfqCDWZMACrtLqoFtEhepyVD6AtHP4nwEPEw9X ygwWsG4kDNoz0RehCiIU6INKhuEooehGrFHTuaGWudOoVZAkDEP6bBBzD5yXGv5YNiqk IhHw== X-Gm-Message-State: ALoCoQlDAgsxbOvwhuwW39gybykLEtmwXijjM+dD/wd4/LgqwM4l5KAW+zyixdkRt3ZvgO4jsaq1 X-Received: by 10.194.62.166 with SMTP id z6mr99515wjr.44.1412885964640; Thu, 09 Oct 2014 13:19:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.130.130 with HTTP; Thu, 9 Oct 2014 13:18:44 -0700 (PDT) In-Reply-To: References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> From: Eric Rescorla Date: Thu, 9 Oct 2014 13:18:44 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b86e1ec080a03050503269e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oO1zpzxcdwSI450uMF36yYAHk74 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 20:19:28 -0000 --047d7b86e1ec080a03050503269e Content-Type: text/plain; charset=UTF-8 On Thu, Oct 9, 2014 at 1:00 PM, Martin Thomson wrote: > On 9 October 2014 12:08, Cullen Jennings wrote: > > I-D.ietf-rtcweb-jsep 2015 May > > https://www.youtube.com/watch?v=dik_wnOE4dk&index=2&t=33s&list=WL > > This is a really large document and a good proportion of it hasn't > been reviewed or discussed ... or written. -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b86e1ec080a03050503269e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 9, 2014 at 1:00 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 9 Oct= ober 2014 12:08, Cullen Jennings <fluff= y@iii.ca> wrote:
> I-D.ietf-rtcweb-jsep=C2=A0 2015 May

https://www.youtube.com/watch?v=3D= dik_wnOE4dk&index=3D2&t=3D33s&list=3DWL

This is a really large document and a good proportion of it hasn't
been reviewed or discussed

... or written.<= /div>

-Ekr
=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b86e1ec080a03050503269e-- From nobody Thu Oct 9 13:23:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CAB1A86E3 for ; Thu, 9 Oct 2014 13:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0F3oRbPDgQN for ; Thu, 9 Oct 2014 13:23:01 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA731A82E2 for ; Thu, 9 Oct 2014 13:23:00 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so1858363lbv.7 for ; Thu, 09 Oct 2014 13:22:59 -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=yOaGqXyj7tnoLOjbhPS1kmnqvvplH5OhTa3QW8OPchM=; b=hMwwXrc4OyqKRBbElnc0nStFI/rPUvtLKqF3A5fBsLlBt5xntK0saeIuV1VWLCP2Jm UOFsv5t6NCKv0IyT3I7eLgqaS6sxxmc26iAhoRefP/ajMOsRnnnwIM75EkmUr57zLvXW tHcYzBM/exM8IkLM8vuONRbcMGAk1grNc2khLkBgAmfXbwTxNyA1He2DojztkqIylrqU ZsfAUevsqftTkVV2FunOpCIc2fB4mhrnNXIxFKUJeu+HXsChmbEWXjQqdgcZRCtpdoCJ P73EdwprkUXZ9fvPkAzNUROQMl2LT8cIM+rLSyyGG8kagbMg56QBLWxik1R/osCb0GAO k9wg== MIME-Version: 1.0 X-Received: by 10.112.142.104 with SMTP id rv8mr19467461lbb.59.1412886179170; Thu, 09 Oct 2014 13:22:59 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Thu, 9 Oct 2014 13:22:59 -0700 (PDT) In-Reply-To: References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> Date: Thu, 9 Oct 2014 13:22:59 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Uaw29AORZZWiuqpleDnsMGpQbc4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 20:23:03 -0000 On 9 October 2014 13:18, Eric Rescorla wrote: >> > I-D.ietf-rtcweb-jsep 2015 May >> >> https://www.youtube.com/watch?v=dik_wnOE4dk&index=2&t=33s&list=WL >> >> This is a really large document and a good proportion of it hasn't >> been reviewed or discussed > > > ... or written. I don't know, it looks like you've been making good progress. You might be half-way. The "Parsing an Offer", "Parsing an Answer", "Applying a Local Description" and "Applying a Remote Description" sections might be empty now, but they aren't that hard. From nobody Thu Oct 9 17:48:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA541AD02C; Thu, 9 Oct 2014 17:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxYSaxgzeMnr; Thu, 9 Oct 2014 17:48:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 868481AD018; Thu, 9 Oct 2014 17:48:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> Date: Thu, 09 Oct 2014 17:48:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QZHbSnr25uiCZ4c9K0URueewQEw Cc: rtcweb@ietf.org Subject: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 10 Oct 2014 00:48:38 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Data Channels' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Oct 9 21:03:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6251A0102 for ; Thu, 9 Oct 2014 21:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ1VueoH6T-O for ; Thu, 9 Oct 2014 21:03:12 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941881A00A3 for ; Thu, 9 Oct 2014 21:03:11 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so2854850wgh.35 for ; Thu, 09 Oct 2014 21:03:10 -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=Y977nblweuKN0eIeEcmVgVaRCeVXvGeTJYkUnaY2aGU=; b=KHcMWDLLmaMtSZ7OVngRq+tjAJfYUMwSjmopEZJIaKDqE2AZa7kWHsNxp65AEwRiu8 jBT3s1GyB7iI1DHVl/cKbB/H0x/2HurNQJwk6jX7MGESkSN9/Le+jGnL2bEndzAhsI+U VNFvai0m4eveeXId7//h7YeIeDTTb42DciaSxC+OtOLKVLKS3LnI+cYbwKMVc8J6CahN VtvfzJt9KUS6p8LFk4lrkG6mlfVxahVFFOJ8kv7HCqGKu38dep8MjVIlkHPsNoQpibkE 40DNBxVclc3PWSjOqf/Cw1iLgry9HvO8gMGyYaKlZHDZ5y1zqPb1RzLuivl5MsKKrTg1 FJkg== MIME-Version: 1.0 X-Received: by 10.180.8.165 with SMTP id s5mr2045416wia.4.1412913790027; Thu, 09 Oct 2014 21:03:10 -0700 (PDT) Received: by 10.180.197.168 with HTTP; Thu, 9 Oct 2014 21:03:09 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47093C@ESESSMB209.ericsson.se> References: <5434B4D9.8000302@nteczone.com> <5435EC15.3040908@nteczone.com> <913383AAA69FF945B8F946018B75898A2833830C@xmb-rcd-x10.cisco.com> <54363020.2040807@nteczone.com> <543632A7.6050401@alvestrand.no> <54363775.40108@nteczone.com> <913383AAA69FF945B8F946018B75898A28338614@xmb-rcd-x10.cisco.com> <54365A2B.9080007@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D47093C@ESESSMB209.ericsson.se> Date: Fri, 10 Oct 2014 09:33:09 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d042184598d908d050509a02f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RRyzuMbG1YJlsnuzKpcl6XzfrPg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 04:03:24 -0000 --f46d042184598d908d050509a02f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 9, 2014 at 5:48 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Why would the receiver have to do anything? Each endpoint uses consent > checks to verify that it can SEND media. > > Also, keep in mind that if the remote peer is ICE lite, it won't send any > consent checks. > =E2=80=8BGiven the security issue with ICE lite, I am wondering whether we = should deprecate it going forward. It was originally conceived as an initial step towards a full ICE implementation, but I think we didn't have WebRTC then := ) Muthu > > Regards, > > Christer > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian > Groves > Sent: 9. lokakuuta 2014 12:50 > To: Tirumaleswar Reddy (tireddy); rtcweb@ietf.org > Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshnes= s > > Hello Tiru, > > I've seen that text but it talks about the receiving endpoint of a STUN > binding response. I was referring to the endpoint that receives the STUN > binding request and sends the response. The draft concentrates on the STU= N > binding request initiator and its notion of consent. It doesn't explain > what notion of consent that the receiver of the STUN binding request. E.g= . > a STUN binding request receiver may close the connection which leads to a= n > immediate revokation but it doesn't mean it has the notion of consent. As > Harald indicates below the receiver may not care at all about it. > > Regards, Christian > > On 9/10/2014 7:29 PM, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian > >> Groves > >> Sent: Thursday, October 09, 2014 12:51 PM > >> To: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Question on > >> draft-ietf-rtcweb-stun-consent-freshness > >> > >> I don't think it should mandate a particular action but I think it > >> would be good to mention some of the possibilities. As it stands > >> nothing is mentioned in the draft about the role of the receiver. > > The role of receiver to immediately revoke consent either using STUN > > error code or DTLS fatal alert is discussed in > > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-07 > > #section-4.2 > > > > -Tiru > > > >> If the receiver watches the 30 second timer, how does it distinguish > >> between receiving a STUN binding request for the purposes of Consent > >> (i.e. linked to application data signalling) and a STUN binding > >> request sent for the purposes of a keep alive? I guess that it uses > >> the fact that consent related STUN binding request are authenticated > >> and keepalive STUN binding requests are not (as per cl.10/RFC5245. Is > that correct? > >> > >> Regards, Christian > >> > >> On 9/10/2014 6:00 PM, Harald Alvestrand wrote: > >>> On 10/09/2014 08:50 AM, Christian Groves wrote: > >>>> Hello Tiru, > >>>> > >>>> So does this mean that the receiver also has to keep track of 30 > >>>> second consent period to be able to identify the situation? > >>> If the receiver cares about being flooded without its consent, the > >>> receiver needs to detect that situation and take appropriate action. > >>> Either by watching the 30-second timer or by some other means. > >>> > >>> If the receiver doesn't care, it doesn't have to do anything. > >>> > >>> I don't think the spec needs to mandate any particular reaction from > >>> the receiver in this situation. > >>> > >>> > >>> > >>> > >>>> Regards, Christian > >>>> > >>>> On 9/10/2014 5:42 PM, Tirumaleswar Reddy (tireddy) wrote: > >>>>>> -----Original Message----- > >>>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > >>>>>> Christian Groves > >>>>>> Sent: Thursday, October 09, 2014 7:30 AM > >>>>>> To: Ram Mohan R (rmohanr); rtcweb@ietf.org > >>>>>> Subject: Re: [rtcweb] Question on > >>>>>> draft-ietf-rtcweb-stun-consent-freshness > >>>>>> > >>>>>> Hello Ram, > >>>>>> > >>>>>> Thanks for the response. A further question. The draft focuses on > >>>>>> sender behaviour with regards to consent, i.e. it indicates that > >>>>>> an endpoint must not send data if consent hasn't been granted. > >>>>>> What about receiver behaviour? > >>>>>> E.g. what happens if the sending end point is not well behaved > >>>>>> and sends application data beyond the consent period, what should > >>>>>> the receiver do ? > >>>>> The receiver can use DTLS fatal error to immediately revoke the > >>>>> consent. But if sender does not care about consent revocation then > >>>>> the receiver has to rely on other techniques (like closing the FW > >>>>> mapping etc.). The javascript may be malicious, hence consent > >>>>> checks are done by the browser (which serves as user's TCB)) and > >>>>> browser has to be trusted to do the right thing. > >>>>> > >>>>> -Tiru > >>>>> > >>>>>> Regards, Christian > >>>>>> > >>>>>> On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote: > >>>>>>> Hi Christian, > >>>>>>> > >>>>>>> Thanks for your comments. Please see inline > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Christian Groves > >>>>>>> Date: Wednesday, 8 October 2014 9:21 am > >>>>>>> To: "rtcweb@ietf.org" > >>>>>>> Subject: [rtcweb] Question on > >>>>>>> draft-ietf-rtcweb-stun-consent-freshness > >>>>>>> > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> I have a couple of comments on > >>>>>>>> draft-ietf-rtcweb-stun-consent-freshness-07: > >>>>>>>> > >>>>>>>> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to > >>>>>>>> both "ICE binding requests" and "STUN binding requests". Is > >>>>>>>> there a distinction between them? e.g. "ICE binding requests" > >>>>>>>> refer to > >>>>>>>> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request > >>>>>>>> indicates a non-extended binding request as per RFC5389. > >>>>>>> We will change it to STUN binding requests to keep it consistent > >>>>>>> with the rest of the document. > >>>>>>> > >>>>>>>> 2) Just to confirm when Consent is first given. Is the 30sec > >>>>>>>> consent period assumed after the initial ICE exchange? > >>>>>>> Paragraph 4 in Section 4.1 has this text. Hope this is sufficient= . > >>>>>>> > >>>>>>> "The initial Consent to send traffic is obtained by ICE. Consent > >>>>>>> expires after 30 seconds." > >>>>>>> > >>>>>>> > >>>>>>>> I found the second > >>>>>>>> paragraph in cl.4.1 not so clear as it talks about subsequent > >>>>>>>> consent before the initial consent in paragraph 5. I'd suggest > >>>>>>>> modifying it along the lines of: > >>>>>>>> "An endpoint MUST NOT send application data (e.g., RTP, RTCP, > >>>>>>>> SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) on an > >>>>>>>> ICE-initiated connection unless the receiving endpoint consents > >>>>>>>> to receive > >>>>>> the data. > >>>>>>>> Initial consent is granted as a result of a successful ICE > >>>>>>>> connectivity check on a particular transport address. Consent > >>>>>>>> expires after a fixed amount of time. As a result, subsequent > >>>>>>>> consent MUST be obtained following the procedure described in > >>>>>>>> this > >> document. > >>>>>>>> During ICE restart consent checks MUST continue to be sent on > >>>>>>>> previously validated pair, and MUST be responded to on the > >>>>>>>> previously validated pair, until ICE restart completes." > >>>>>>> Sure will make this change. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Ram > >>>>>>> > >>>>>>>> Regards, Christian > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d042184598d908d050509a02f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Th= u, Oct 9, 2014 at 5:48 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=
Hi,

Why would the receiver have to do anything? Each endpoint uses consent chec= ks to verify that it can SEND media.

Also, keep in mind that if the remote peer is ICE lite, it won't send a= ny consent checks.

= =E2=80=8BGiven the security issue with ICE lite, I am wondering whether we = should deprecate it going forward. It was originally conceived as an initia= l step towards a full ICE implementation, but I think we didn't have We= bRTC then :)

Muthu
=C2=A0

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Christian Groves
Sent: 9. lokakuuta 2014 12:50
To: Tirumaleswar Reddy (tireddy); rtcweb= @ietf.org
Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness<= br>
Hello Tiru,

I've seen that text but it talks about the receiving endpoint of a STUN= binding response. I was referring to the endpoint that receives the STUN b= inding request and sends the response. The draft concentrates on the STUN b= inding request initiator and its notion of consent. It doesn't explain = what notion of consent that the receiver of the STUN binding request. E.g. = a STUN binding request receiver may close the connection which leads to an = immediate revokation but it doesn't mean it has the notion of consent. = As Harald indicates below the receiver may not care at all about it.

Regards, Christian

On 9/10/2014 7:29 PM, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message-----
>> From: rtcweb [mailto:rt= cweb-bounces@ietf.org] On Behalf Of Christian
>> Groves
>> Sent: Thursday, October 09, 2014 12:51 PM
>> To: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Question on
>> draft-ietf-rtcweb-stun-consent-freshness
>>
>> I don't think it should mandate a particular action but I thin= k it
>> would be good to mention some of the possibilities. As it stands >> nothing is mentioned in the draft about the role of the receiver.<= br> > The role of receiver to immediately revoke consent either using STUN > error code or DTLS fatal alert is discussed in
> http://tools.ietf.org/html/draft-ietf-rtcweb= -stun-consent-freshness-07
> #section-4.2
>
> -Tiru
>
>> If the receiver watches the 30 second timer, how does it distingui= sh
>> between receiving a STUN binding request for the purposes of Conse= nt
>> (i.e. linked to application data signalling) and a STUN binding >> request sent for the purposes of a keep alive? I guess that it use= s
>> the fact that consent related STUN binding request are authenticat= ed
>> and keepalive STUN binding requests are not (as per cl.10/RFC5245.= Is that correct?
>>
>> Regards, Christian
>>
>> On 9/10/2014 6:00 PM, Harald Alvestrand wrote:
>>> On 10/09/2014 08:50 AM, Christian Groves wrote:
>>>> Hello Tiru,
>>>>
>>>> So does this mean that the receiver also has to keep track= of 30
>>>> second consent period to be able to identify the situation= ?
>>> If the receiver cares about being flooded without its consent,= the
>>> receiver needs to detect that situation and take appropriate a= ction.
>>> Either by watching the 30-second timer or by some other means.=
>>>
>>> If the receiver doesn't care, it doesn't have to do an= ything.
>>>
>>> I don't think the spec needs to mandate any particular rea= ction from
>>> the receiver in this situation.
>>>
>>>
>>>
>>>
>>>> Regards, Christian
>>>>
>>>> On 9/10/2014 5:42 PM, Tirumaleswar Reddy (tireddy) wrote:<= br> >>>>>> -----Original Message-----
>>>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of
>>>>>> Christian Groves
>>>>>> Sent: Thursday, October 09, 2014 7:30 AM
>>>>>> To: Ram Mohan R (rmohanr); rtcweb@ietf.org
>>>>>> Subject: Re: [rtcweb] Question on
>>>>>> draft-ietf-rtcweb-stun-consent-freshness
>>>>>>
>>>>>> Hello Ram,
>>>>>>
>>>>>> Thanks for the response. A further question. The d= raft focuses on
>>>>>> sender behaviour with regards to consent, i.e. it = indicates that
>>>>>> an endpoint must not send data if consent hasn'= ;t been granted.
>>>>>> What about receiver behaviour?
>>>>>> E.g. what happens if the sending end point is not = well behaved
>>>>>> and sends application data beyond the consent peri= od, what should
>>>>>> the receiver do ?
>>>>> The receiver can use DTLS fatal error to immediately r= evoke the
>>>>> consent. But if sender does not care about consent rev= ocation then
>>>>> the receiver has to rely on other techniques (like clo= sing the FW
>>>>> mapping etc.).=C2=A0 The javascript may be malicious, = hence consent
>>>>> checks are done by the browser (which serves as user&#= 39;s TCB)) and
>>>>> browser has to be trusted to do the right thing.
>>>>>
>>>>> -Tiru
>>>>>
>>>>>> Regards, Christian
>>>>>>
>>>>>> On 8/10/2014 5:41 PM, Ram Mohan R (rmohanr) wrote:=
>>>>>>> Hi Christian,
>>>>>>>
>>>>>>> Thanks for your comments. Please see inline >>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Groves <Christian.Groves@nteczone.com>
>>>>>>> Date: Wednesday, 8 October 2014 9:21 am
>>>>>>> To: "r= tcweb@ietf.org" <rtcweb@ietf= .org>
>>>>>>> Subject: [rtcweb] Question on
>>>>>>> draft-ietf-rtcweb-stun-consent-freshness
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I have a couple of comments on
>>>>>>>> draft-ietf-rtcweb-stun-consent-freshness-0= 7:
>>>>>>>>
>>>>>>>> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-f= reshness refers to
>>>>>>>> both "ICE binding requests" and = "STUN binding requests". Is
>>>>>>>> there a distinction between them? e.g. &qu= ot;ICE binding requests"
>>>>>>>> refer to
>>>>>>>> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and = STUN binding request
>>>>>>>> indicates a non-extended binding request a= s per RFC5389.
>>>>>>> We will change it to STUN binding requests to = keep it consistent
>>>>>>> with the rest of the document.
>>>>>>>
>>>>>>>> 2) Just to confirm when Consent is first g= iven. Is the 30sec
>>>>>>>> consent period assumed after the initial I= CE exchange?
>>>>>>> Paragraph 4 in Section 4.1 has this text. Hope= this is sufficient.
>>>>>>>
>>>>>>> "The initial Consent to send traffic is o= btained by ICE.=C2=A0 Consent
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 expires after 30 se= conds."
>>>>>>>
>>>>>>>
>>>>>>>> I found the second
>>>>>>>> paragraph in cl.4.1 not so clear as it tal= ks about subsequent
>>>>>>>> consent before the initial consent in para= graph 5. I'd suggest
>>>>>>>> modifying it along the lines of:
>>>>>>>> "An endpoint MUST NOT send applicatio= n data (e.g., RTP, RTCP,
>>>>>>>> SCTP, DTLS), over any transport protocol (= e.g., UDP, TCP) on an
>>>>>>>> ICE-initiated connection unless the receiv= ing endpoint consents
>>>>>>>> to receive
>>>>>> the data.
>>>>>>>> Initial consent is granted as a result of = a successful ICE
>>>>>>>> connectivity check on a particular transpo= rt address. Consent
>>>>>>>> expires after a fixed amount of time. As a= result, subsequent
>>>>>>>> consent MUST be obtained following the pro= cedure described in
>>>>>>>> this
>> document.
>>>>>>>> During ICE restart consent checks MUST con= tinue to be sent on
>>>>>>>> previously validated pair, and MUST be res= ponded to on the
>>>>>>>> previously validated pair, until ICE resta= rt completes."
>>>>>>> Sure will make this change.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Ram
>>>>>>>
>>>>>>>> Regards, Christian
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> rtcweb mailing list
>>>>>>>> rtcweb@= ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcw= eb
>>>>>> _______________________________________________ >>>>>> 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

--f46d042184598d908d050509a02f-- From nobody Fri Oct 10 03:47:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6C1A8A0D for ; Fri, 10 Oct 2014 03:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8LFfPy7SsSb for ; Fri, 10 Oct 2014 03:47:48 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129F51A8A0E for ; Fri, 10 Oct 2014 03:47:48 -0700 (PDT) Received: from [130.209.247.112] (port=58913 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XcXjd-0006jr-9h; Fri, 10 Oct 2014 11:47:46 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> Date: Fri, 10 Oct 2014 11:47:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mJYsm6kyo7b85ys2iwKpip0KVOI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 10:47:50 -0000 On 9 Oct 2014, at 20:08, Cullen Jennings wrote: > Once again, the chairs are updating dates for documents. I'm forming a = list of when we hope to have an RFC for various drafts. In many ways the = relative ordering of when these drafts is probably more accurate than = the actually dates. The straw man for dates is =85 > I-D.ietf-rtcweb-rtp-usage 2015 Jan The only open issue with this draft is FEC support. Varun recently = submitted draft-singh-payload-rtp-1d2d-parity-scheme-00 as a possible = FEC scheme for WebRTC. Feedback from the working group on whether that = draft is suitable to be referenced from the rtp-usage draft would be = helpful. --=20 Colin Perkins https://csperkins.org/ From nobody Fri Oct 10 03:52:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9D1A8A04 for ; Fri, 10 Oct 2014 03:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNur2CG-HhM2 for ; Fri, 10 Oct 2014 03:52:48 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 598251A8A10 for ; Fri, 10 Oct 2014 03:52:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3319E7C0BFC for ; Fri, 10 Oct 2014 12:52:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvq8oHQUk5PI for ; Fri, 10 Oct 2014 12:52:45 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:fd33:f515:b48d:7f77]) by mork.alvestrand.no (Postfix) with ESMTPSA id C021A7C0BEA for ; Fri, 10 Oct 2014 12:52:45 +0200 (CEST) Message-ID: <5437BA7C.6060402@alvestrand.no> Date: Fri, 10 Oct 2014 12:52:44 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> In-Reply-To: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/N1QGLM7EM42MlApvIR4AqXW1dgI Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 10:52:51 -0000 I'd like the chairs to indicate whether or not they are going to entertain -gateways for WG draft status too. On 10/09/2014 09:08 PM, Cullen Jennings wrote: > Once again, the chairs are updating dates for documents. I'm forming a list of when we hope to have an RFC for various drafts. In many ways the relative ordering of when these drafts is probably more accurate than the actually dates. The straw man for dates is > > I-D.ietf-rtcweb-alpn 2015 Feb > > I-D.ietf-rtcweb-audio 2015 May > > I-D.ietf-rtcweb-constraints-registry 2015 Jan > > I-D.ietf-rtcweb-data-channel 2014 Dec > > I-D.ietf-rtcweb-data-protocol 2014 Dec > > I-D.ietf-rtcweb-jsep 2015 May > > I-D.ietf-rtcweb-overview 2015 May > > I-D.ietf-rtcweb-rtp-usage 2015 Jan > > I-D.ietf-rtcweb-security-arch 2015 Dec > > I-D.ietf-rtcweb-security 2015 Dec I assume "2014 Dec" is the intended target date here? > > I-D.ietf-rtcweb-stun-consent-freshness 2015 Feb > > I-D.ietf-rtcweb-transports 2015 Jan > > I-D.ietf-rtcweb-video 2015 May > > If you are an author or involved with these drafts or just have a strong opinion on what the date to be an RFC will be and want to use a different date than the ones above, let me know. > > Thanks, Cullen > > If you are interested, I have a document where I track the dates of most the normative dependencies for WebRTC at > > https://tools.ietf.org/html/draft-jennings-rtcweb-deps > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Oct 10 05:22:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543361A9119 for ; Fri, 10 Oct 2014 05:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3f5oRSDxSwX for ; Fri, 10 Oct 2014 05:22:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9FB1A9118 for ; Fri, 10 Oct 2014 05:22:46 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-af-5437cf94f073 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.29.04081.49FC7345; Fri, 10 Oct 2014 14:22:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 14:22:44 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Consent Freshness: Connection liveness/heartbeats Thread-Index: Ac/khDonWu2om5LnTYiCouL4O3PwFQ== Date: Fri, 10 Oct 2014 12:22:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D474980@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D474980ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje7U8+YhBu13mS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs1Zb1kKZnlVXPpzhK2BcZljFyMnh4SAicSHp58ZIWwxiQv3 1rN1MXJxCAkcZZTYvP0wM4SzhFGib8J91i5GDg42AQuJ7n/aIA0iAuoSlx9eYAexhQWsJPb9 O8IIEbeXuDWxgQnC1pO49vwYmM0ioCoxpe0gO8gYXgFfib6X2SBhRqC930+tASthFhCXuPVk PhPEPQISS/acZ4awRSVePv4HdoGEgJLEtK1pEOX5Eqd3rmADsXkFBCVOznzCMoFRaBaSSbOQ lM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYn5aYbGemlFmUmFxfn5+nl pZZsYgTGw8Etvw12ML587niIUYCDUYmHd4GteYgQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamCU2K9hIqctPaO1ySPoZUN498572x8V70/9fq5qtrDVzis1 Z37rizp3c12Ywvo7f9HfCLmcRyX/v01WEQzk3GSsNenGc9FZXwQ3toTe1i/9Us2w4ZKHtqJ9 z+Nvq57uVEqwTLuo+1DhSVJHi7pl0OtFszYbujyW+ffSftJtTZcW//Dmt9Jtk/8qsRRnJBpq MRcVJwIAARjGhmgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vEoQVSKDjDNashH6zmYm_CyAf3c Subject: [rtcweb] Consent Freshness: Connection liveness/heartbeats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 12:22:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D474980ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have some questions on the connection liveness/heartbeat section of the d= raft. Q1: =3D=3D=3D The text says: "Similarly, if packets haven't been received within a certain perio= d, an application can request a consent check (heartbeat) be generated= ." BUT, if an endpoint is anyway sending consent requests every 5th second, wh= y aren't the those enough as hearbeats? As long as the endpoint receives re= sponses, it knows the remote endpoint is alive (the text even says that an = endpoint is considered alive as long as some data is received from it). And, if the endpoint does NOT receive responses to the consent requests, co= nsent will expire anyway. I DO understand that an ICE lite may want to send a heartbeat request if it= does not receive any data, as it doesn't send consent requests. Q2: =3D=3D=3D The text says: "Sending consent checks (heartbeats) at a high rate could allow a malicious application to generate congestion, so applications MUST NOT be able to send heartbeats at an average rate of more than 1 pe= r second." I don't think applications should be alowed to generate heartbeats this oft= en, and I see no need for it. Q3: =3D=3D=3D The spec is unclear on what happens is a response to a heartbeat request is= not received. I guess that is an application decision, but I think the spe= c should be clear that it does NOT have any impact on consent - the "real" = consent requests are used to determine. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D474980ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have some questions on the connection liveness/hea= rtbeat section of the draft.

 

 

Q1:

=3D=3D=3D

 

The text says:

 

        “Similarl= y, if packets haven't been received within a certain period,

        an application can r= equest a consent check (heartbeat) be generated.”

 

BUT, if an endpoint is anyway sending consent requests eve= ry 5th second, why aren’t the those enough as hearbeats? A= s long as the endpoint receives responses, it knows the remote endpoint is alive (the text even says that an endpoint is consi= dered alive as long as some data is received from it).

 

And, if the endpoint does NOT receive responses to the con= sent requests, consent will expire anyway.

 

I DO understand that an ICE lite may want to send a heartb= eat request if it does not receive any data, as it doesn’t send conse= nt requests.

 

 

Q2:

=3D=3D=3D

 

The text says:

 

        “Sending consent chec=
ks (heartbeats) at a high rate could allow a
        malicious application to generat=
e congestion, so applications MUST
        NOT be able to send heartbeats a=
t an average rate of more than 1 per
        second.”
 
I don’t think applications should be alowed to generate heartbea=
ts this often, and I see no need for it.

 

 

Q3:

=3D=3D=3D

 

The spec is unclear on what happens is a response to a hea= rtbeat request is not received. I guess that is an application decision, bu= t I think the spec should be clear that it does NOT have any impact on consent – the “real” consent requ= ests are used to determine.

 

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D474980ESESSMB209erics_-- From nobody Fri Oct 10 07:25:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1762D1ACE16 for ; Fri, 10 Oct 2014 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60bqx-NgLFrB for ; Fri, 10 Oct 2014 07:25:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A0F1A1A9E for ; Fri, 10 Oct 2014 07:25:24 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 31B3D18C0DC for ; Fri, 10 Oct 2014 16:25:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0B54F35C060 for ; Fri, 10 Oct 2014 16:25:22 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 16:25:21 +0200 From: To: "'rtcweb@ietf.org'" Thread-Topic: Work progress on draft-ietf-rtcweb-audio-codecs-for-interop Thread-Index: Ac/klgVRU8bwP7yQTiuT/3l6b6edyQ== Date: Fri, 10 Oct 2014 14:25:21 +0000 Message-ID: <19916_1412951122_5437EC52_19916_691_8_2842AD9A45C83B44B57635FD4831E60A0C1D3C8A@PEXCVZYM14.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/mixed; boundary="_002_2842AD9A45C83B44B57635FD4831E60A0C1D3C8APEXCVZYM14corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.8.100919 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Y1KWvsxKeBwWr8itWiMKrlNR0Ew Subject: [rtcweb] Work progress on draft-ietf-rtcweb-audio-codecs-for-interop X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 14:25:29 -0000 --_002_2842AD9A45C83B44B57635FD4831E60A0C1D3C8APEXCVZYM14corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, This document (http://tools.ietf.org/id/draft-proust-rtcweb-audio-codecs-fo= r-interop-00.txt) being now a shared working document, I would be happy to = get the views of the Group on how to jointly progress and improve it. In order to trigger this discussion, I would propose the following modifica= tions with 2 main purposes: 1) Remove any reference to "legacy" (and the corresponding definition secti= on n=B03): Even with the definition in section 3, this word "legacy" remain= s unclear and not really needed for the understanding of this draft: there = are no reasons to limit the possible WebRTC interoperability use cases to "= legacy" interop assuming we know clearly what "legacy" covers: any interope= rability could be relevant if justified by real and significant use cases. 2) Emphasize and detail for AMR and AMR-WB some concrete points related to = codec offer that are important for interoperability (which is indeed the co= re motivation of this draft) As Editor of the document, I would be happy to consider any other additiona= l text you may propose and include it in the document if agreeable by the G= roup Best regards St=E9phane ---------------------------------------------------------------------------= ---------------- Proposed changes: Modif 1 Title [Additional WebRTC audio codecs for interoperability with legacy networks. ] ->=20 [Additional WebRTC audio codecs for interoperability. ] Modif 2 [3. Definitions - Legacy networks... ] -> removed Modif 3 [4. Rationale for additional WebRTC codecs ...The WebRTC technology is however expected to have more extended usage to communicate with other types of clients. It can be used for instance= as an Access technology to 3GPP IMS services or to interoperate with fixed or mobile VoIP legacy HD voice service...] -> [4. Rationale for additional WebRTC codecs ...The WebRTC technology is however expected to be used to communicate w= ith other types of clients using other technologies. It can be used for inst= ance as an access technology to 3GPP IMS services (e.g. VoLTE, ViLTE) or to i= nteroperate with fixed or mobile Circuit Switched or VoIP services like mobile 3GPP 3G/2G Circuit Switched voice or DECT based VoIP telephony...] Modif 4 Text added to section [5.1.3 Guidelines for AMR-WB usage and implementation= with WebRTC] [ In order to maximize the possibility of successful call establishment for= WebRTC client offering AMR-WB it is important that the WebRTC client:=20 - Offer AMR in addition to AMR-WB with AMR-WB, being a wideband codec,=20 listed first as preferred payload type with respect to other narrow ba= nd codecs (AMR, G.711 .) and with Bandwidth Efficient payload format prefe= rred.=09 - Be capable of operating AMR-WB with any subset of the nine codec modes a= nd source controlled rate operation. - Offer at least one AMR-WB configuration with parameter settings as defined in Table 6.1 and in Table 6.2 of [TS26.114].In order to maximize the interoperability and quality this offer do not restrict the codec modes offered. Restrictions in the use of codec modes may be included in the a= nswer ] Modif 5 Text added to section [5.2.3. Guidelines for AMR usage and implementation = with WebRTC] [In order to maximize the possibility of successful call establishment for = WebRTC client offering AMR, it is important that the WebRTC client:=20 - Be capable of operating AMR with any subset of the eight codec modes and source controlled rate operation. - Offer at least one configuration with parameter settings as defined in Table 6.1 and in Table 6.2 of [TS26.114].In order to maximize the interoperability and quality this offer shall not restrict AMR codec mod= es offered. Restrictions in the use of codec modes may be included in the a= nswer. For convenience, I attach a version in Word format with changes as revisio= n marks ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_002_2842AD9A45C83B44B57635FD4831E60A0C1D3C8APEXCVZYM14corpo_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-rtcweb-audio-codecs-for-interop-00-rev20141010.docx" Content-Description: draft-ietf-rtcweb-audio-codecs-for-interop-00-rev20141010.docx Content-Disposition: attachment; filename="draft-ietf-rtcweb-audio-codecs-for-interop-00-rev20141010.docx"; size=51508; creation-date="Fri, 10 Oct 2014 13:09:08 GMT"; modification-date="Fri, 10 Oct 2014 14:25:20 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBJn4PiqwEAAJcGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lc1u2zAQhO8B+g4Cr4FEJ4eiKCznkCbH1EAdpFeaWtlE+QfuOrHfvivZFpxWtdw4uQiQyJ35OOCu xjdrZ7NnSGiCL8VVMRIZeB0q4xeleJzd519EhqR8pWzwUIoNoLiZfLoYzzYRMONqj6VYEsWvUqJe glNYhAieV+qQnCJ+TQsZlf6lFiCvR6PPUgdP4CmnRkNMxt+gVitL2d2aP29JElgU2e12Y+NVChWj NVoRk8pnX/3hku8cCq5s9+DSRLxkDCF7HZqVfxvs6r5zNMlUkE1VogflGEO+hFTJKuiV4zMUx2V6 OENdGw1dfaMWU9CAyJk7W3QrThm/5+/j0Cuk4H46Kw2Bm6YQ8epsnE600YNEBroM+xjaLPzKzSEx /dnuf4XRSR8LooVA2ljA9yfY6p5o/2RoeVfXoPnWD18Mh3mDXmwtDmqH3YCI8z7F5HUv5kO3D3fK gwgvMP/xYRQH4oMgNc+ImZpbOCHx/wyjkx6EIB58INvn+T3Yyhyz5BHRtjsP0vSGY+8nZVOd8+w5 oc87Rx7CZ+cMzZivoOrxlu1vZfIbAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03 Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1 nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQAqQskQQwEAAMwE AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKyUMU/DMBCFdyT+Q+SdOCnQItSkCyB1hSJYXeecWMR2ZF+A/nsOooZULWHJ eM/yvU/Pd16uPk0dvYMP2tmMpXHCIrDSFdqWGXvePFzcsCigsIWonYWM7SCwVX5+tnyEWiBdCpVu QkRdbMhYhdjcch5kBUaE2DVg6UQ5bwRS6UveCPkmSuCzJJlzP+zB8oOe0brImF8X5L/ZNeT8f2+n lJZw52RrwOIJC47EBdRQ+BIwYz9lJ6YxgTJ+muFySoaAu5pC7CG6esx+MaW9chY3YlsPYuilMYjZ lBC2NVvwNGO/MfTSGEQ6JYRsAzrzSs/ev0Uc817lGsGMjsV8SpoP2D4BImUymI2BOBbL9ZQg4Yhi r4whXP2BYLT0LjiFsXSGdxv6vZmLw+Xn3Ra8aKzulQKJgxCOjvYc/OAPyr8AAAD//wMAUEsDBBQA BgAIAAAAIQAlqY+bIoUAADLSDAARAAAAd29yZC9kb2N1bWVudC54bWzsfWlz48aW5feJmP+QwS9t R0gqblqjxQ6VFr+KscsaSX6eaYdjAgSSUj6BAB8WqeR/1L+j/9icTIASkwRAUoufCRz3IhXFYpFX mXc599xz//0/vo198SCjWIXBcauz024JGbihp4Lb49YvNxfbBy0RJ07gOX4YyOPWk4xb/zH4n//j 3x+PvNBNxzJIBF4iiI8eJ+5x6y5JJkefPsXunRw78c5YuVEYh6Nkxw3Hn8LRSLny02MYeZ+67U7b fDeJQlfGMf69Uyd4cOJW/nLjxVcLJzLAvzUKo7GTxDthdPtp7ET36WQbrz5xEjVUvkqe8NrtvenL hMetNAqO8je0/fyG9F85yt5Q/mX6N6KFT1Hw72Z/8yy3gPkXP0XSx3sIg/hOTV4+xmtfDR/xbvqW Hqo+xMPYnz7vcdLpL/x7zx95ld/BWeQ84lfx8oILL1dgDC/7S2M/s4P+/b78VudfsdOu+jD5b0S/ xPN7WOUt2P/m9J2MHRU8v8zrTDNrXNyIt5zvH6IwnTy/nYl626t9Ce6fX0tfzDXeWXvP3LzZjxav 9QILV/f6zpnIlhi7R19ugzByhj7e0WOnL/SJbA3gLIah96S/TsTjEZyNd3Xcarfbvf7uwXlr+tAl rt7Cg2dy5KR+sviTy5mHzCtfRvpL4gzj/Cte98Hxj1u+HCX6H5mE+JiHnb3Wp6ondA563epndPf7 B9XP6O3t9aufgQ/ern7Gbv9wyTvd63eWvNP9XnfJOz3o9pe8UxhsyTvttNv7S95qp314uOS9djqH 7SVvttPF2622Wqe331/2dvt7u+btfno5LVF2eKKLMEhiHBUndhUu6GmYRkpG4qt81AdIOnFyEivn uHWjxjLWD4urcOzAyTwe3Z0E8eJfcXHkZl/FHL34j1P9j5jD2c3fre8Et9Y/MYq2L670h8XbNG8P Xyf6beqv5sDj6bxKxy1epXkfx6vEq1QQ+hiV5nIBRqU8tjEqWTkiEzw7Z2aC934Jnkn6ZLD9y7Wd UZame0jypomeVSDpFPAvk7au/KmQcg++ygT1+r34Ff8PYIMwhbFY+b/rHXGJUjpOdCacZPkxs+L5 HJBZ8bxFmBXrrHjlmzotN+vnf74EiYwCmWwDmxwlK/udmSf+HKFal/Q/Gd42PVVWDkX/Q/9TBHDR /wy0/wk86enGWpLGR+JLkPW00Dxy/Bk3U/zt+Y74LKNbGdH/0P/A95q2BqGMFaEM+p/B+beJiiT8 zoUcRqkTPYnO7pZAR3632OEUPHqqYjek/6H/of9Zs8FH/6MJPkfxxHHBEZjAD8noQbYGBU5mnYc+ 7wjLHSEsRmE4Oo80eJY8TfBvxRPp+9eJEyVZC7lusNqFVMgrV7LCeeDlnWV2kme4IaxZWbOyZl3o RMCBvq/PPpNpohmZ4kb68j4cWz6L9Ba7+UanRKdEp/TxTinPNplIDj6nINgzkdRU4sLWBnlU5FFl hOB12b0s/t83kZwiBOeRcuM4tH0WE0kmkkuGBThyMA1wjWakfYBT+l9o0oa3KpCBYnXLNgnbJGyT rONq3x1y+7uM1B9hIH5F59fHvDWdEp0SnRKd0r/UKU3LNyF+2hE/SmZKVXPp7AOwD8A+wJ/WB4Bv +lvqPNIpVYpl0CnRKdEp/VlOCcx/q25rIMntJwd6YXPU4zIzkOU2ze45mVUZxTgZyslQDQe9dx9A 09ugMyi+JI6vHMt1sznJ5iSbk4+ZCSr00MiYeGendJLeQjpDdPpm4qtPp8Q+APsAH90HYLRntGe0 /4Bo/9qLdSaB27Xbu/v7h+enLThAI6RarTWcP9lIr1JreEFYmVrDBZKbnXKtYU/6OHfKwznUB9BJ k7sQAtjXyX//1+TOCWQucqZ/5jkJ5lcxoN/f7rS324c3nf2j3d2jdvs/M6fyr5ctZppenqafeJ7S ewEg7WJl22WwZY1HlH+Vw6ub05WskIO3tVMfKzknTuqpUGDxhnRjATUgobRIGZYtQEzfbLWYPzsv 7qPzKvdxYNyHEZGchj9LXjJ/0A6Um6o5CWPdyG8l+N6jSu6MdfNnGS3JTGcdj+iPjC8wh3bV3VfZ OnPVzbL1wJe3jvuk73qJXV+bu10tpmnatEYbHyAu9z+8LLtgTrZeTraRidSLd+rRO8FPv2zpKOjL 576oJAq/EBKLvoNkqNYtjnf+HKeWR2DuueGeG1NeWU38Td9zw4JxuQtaVifdRs64xsUi1sqNku05 I0S5VzT7w3Y/d7Cty+wX20wlfCWTUdkHtKqxTS28ksF2lLiPcrhtClxsXdQF7jYK3O28wN1ulxnA ALSb/hue/3QLqnT6EpOohlu9GONILia52JyKuR15a+cO74g0MCkH0qL3aDIpX3RYTMrzja6bm66c DOMkclzuFtK/wjIBLAZmBmYG5jkRNC4NtDleXBqo0fj32Qq9dsbblLa5EDehkEGcRlI4YujE0ofm kvDlA1q24Wixiz4Ehi9lMN9NXyjL6y4Wvz4Tg0WU7d+YBDEJepckqDm+eg7pXXC6NW9ouL6SQWJL bxWQAGcQ4dodjcGW+O3LfE9n4RzUPfie7RQ0foqtUFca5KDxhyDriy1zieYq1PcQmK7g7yKS/0z1 Sjrk8GMVqHE6FrFMdAKfNQwN44arvkv06JmJMhNlJlpA9ishfGtpr/AREEG0JZJQjJ1vaqz+kCLB RiL0tmKVM+7xM4kVvUNfxXfmhzGEUzHIITRjPEzZI2CPQEN83L97GqaR4v7dVTT0q1RmluWCNS+P 4X5XsUBdk+ESPmggsSheD4RlE2JoTgdYveyp4HZLqEQo5Mx+HCKDhtDQWJq18ohbKnD91JP4apmU GC4xXOoQfIAOQe2AuhJvJJY2zhik6ozflhyLcDRC+hcigkciTpWumdCPnR1pTu6cRDi6S/vgKN/8 HGFqPuQzPjE+MT4xPumyunKMsxzZsfLdku5ajYemhlH4GMtoFSvUtZAasFtAYI7A3IfvpmWyxmSN yRqTtTckazd3wC+90E2BXCYCDJgH5YEFEIdjKW5TfK/ZvLFAy0335p4ry1wmCwXk0IaM6ZLokuiS 6JLe4JJWqZxqXD+6YRDD70bSW8UQdS0hS2BO3YZbZpa6c1fXHxxpSm8kp3drSpHjeWAzxiZrGYdY t6CXLj84ASlDRCaITHw4MtEUj9P4buy8SPKy4NzA1mwaS+FiLjZTrSSHnhx6rd7TaR8edlkpf0Cl TAiKEBQv1gdcrNoldQPASEkKdHskDA7+kxyHVgJDV0JXQlfyAa6EF4sXixfrAy5W7WJ0SSMAslO6 c/1F72jCVojtMy1Vrmdx4nQ4VkmCkR0ViFHq+xhgD9A2GDuBK83cKDnP/eqrx2l2TrNzmn2taXar amge59nwhvRgfqOllUpCFarLz6eXYv9AOIGXfXtIgjTbkGxDfngbkmUmy8zqXLfTOWwfLHlK96C7 JGPm2oFNXztQErvFXIUJrQdM0OodhJB/eOZNGwRZ86On5ag4D27Bm5YRnmWlhnRIdEhLvA0dEkZP Kbde6pBunPheXIQR0KzvvpzfXHy/I8TXMNHiaRjwzxQAbqMwncTQVXvKtGk8hZ0qapgmHNZg3cG6 48Prjuag8FZ20zzgK88EV7FCwyY1pjOFyJjn2zQxItYNsmWoemYKw2kU6enDafZsC1MzZWbKzJSZ rWJOFOrU1XeAO6xRH0HtdGB64zGa4wxTE8eVx60JRsNk9CBbA4GS6S5JJkefPnkOyIBYPHkvI7Mc YieMbj95mlYQf3KzCPWJbRuWTyyfPrx8YsrHlI8pH1O+N6R8z7Vknvzoto0J5jNNG4DMKlf2zlZQ YOkNyBqx+ibGYZDc2fkSnRKdEp0SndIbnNIq9VeNlW1Af1vFAg0DSnWTbihFOkEBKr0tCJVMfFSp +A5aN+EwDn2p2ezDp7y3NwOsQs87eLJMyiDFIMUgxSDFIPVasDRRY5skUdLUrGuUGqA598VMUqnA mYDYP4kUApPW1NJCJgt1VYyAhdUTEtNVjEQA6LF5Y4rP+3KU6Ito1tNxqIpDVRyq4lDVcWvFJYWD MdwufK9vudWGRaMSFiQqI8QjVxnWowRqB/I1HrpzAs02aWlWjh7/RfS61SqQOy3LhiySWCSxSPqA IokXixeLF4sX61MVS6S7318ycNfb21syb8diisXUuxRTjFiMWIxYHxCxSurUGnc3LzFzFydbQqIr 59tE0RJj1BVCLinaxfS/828ThbJcXMhhlDrRk+jsboluu7M7fUL+9bdL51aKzu8s3okrT2F0ymYD 6PoqP8BjMxViKsRU6AMuVkOGge3OcB7CrdBdkAZxV9cE80jGCg3LBp3UU2jhhJ50Y8G1bslAaSnb cLLSjWnYWZnWBSfpLUosXSr0LTMxdWHqwtTlA1IXXixeLF4sXiw29J55nIedvfaSK9Fu7+8tewqX v30MitWQYhsZcdH+i0eFfRfSwOsiDBYBdrstwejO6L7ET1GMdErmX4W1qy/UZTTQtelEU2Am+MtR rLyr41a7nSskTx+6jAoePJMjJ/WTxZ9czjxkXln/M2bYIK7i2iBYLfkFH/SWLCElXcd2Eh1Gdxzh u5MgVset0zCNVN6QwqMfLgxTu+g+OA0nT5G6vUu0hq/iDFVlpUHaH2l/pP0d2wGJAdq2BwO0xioY oP84jWGHN7kLJNilXLaXwP2d+71pSQmtxi9uIt2i0pu+9EKQiYxibEUTyoPAsRopCHlgQA0/Yf+K nDYcTzMaTk7bR3Ha6lYv+E6cXMnAg96Cp8mxnyPp3Gcpc6mjsjwNTlwUhqPzKMLhS540+eQ2csY1 pmVP5ZJWMUPDaBVOmtyFkVbjPwFsbKpQreZhpJE9QsVVwBorUVaib0otCRUPp9k5ZXIqQS9uqFxr 4cH0YtUt9SuvRE0jeJrmYMuDiNPhP6SbaImUmcXTuhx9qVD/LRY/yts5cRn2rWwoiVGeUf5donxz nBGmYB9UrDTmdSV9J9FrcuGHjOM5C910DByMuuosLZ75dAS/CH6twq2pwuK/y1c4JRp7l/JlfZOP jnoQy20VjMLvtSKcHI10ZgRunE6HtOI2Nj5Y0BBzIOZASzhTJMVNS/dVLm7zCjLLnzQPcZ+kQ/hd pH5hsIolGga6Y8FQcocifVqwA32/9KUDae1IPij5qAMT/jD9MXNl5srMlUksXQsDrcqVV3HJNW4H u1gEN0p9316bUxKk6xqaBls5C+lJeDJ2I4X9Q0+gck97wJq9hD5wEilXR3HwqFRypx+ZoHiyDhCr JVZLrJY+YEC4OYix5U9KHHGNA1ISrmKAukaiEtbafIV0CpkgcRqOJ2Gg+wcYcdWb2vVavFEUju2C SowBAlo2ZZBikGKQYpDSdTSQluQkVs5xi6uIVl9FpALXTz17aKEkVDcsUl2r8cTPBjs+X5+JH7OG k0gQoXSNNS2vPN18ukb1hHJK9HfYdeKCh9nlgGyCswm+Si+NwF5Z5B7Mz9QxPMnWIJ9GNExPMUPN 0gAfgFC9IO8Bo4meAfjCNBGPThQ5QfKE2MUSihOKSJg5oTgrcmKY+vE7jBaTFdG0OcS80eJZfpVR Skcp1EaajldcS3EQkQwIMiA+nAFBkJwgOUFyguTLQfLBjTP0NYKJjhx2VnCep/racIiQQ4TvMkTI CM0IXe1qKBWwFk22eRhMB9MG2NMWhV6atSLFzpr/I0TPAjDolOiU6JRYNiwvG0qofkJ04ZRuZDRW QeiHt09rOiTtwOiUqq8gSxCWIO9SgjSHld6DV8E2DhWobAJm3TyJTmmPFC9SvEAg+PDORXOcUh9e 5coM1jsAYPXSZMfzjINyfGGVZQV9Za7abuqq7XzJdklizeSZyfMoYYedcWot8LSKiryLOHXyEpni VCWmZZg7Ih24GK2GVzenK1mhYRM1ZZWWELuWuYg8E3mujtxsh63l0ZvXDoNL2elYTqWgbqr5fhQd qn+6WsUIdY1Dg+1fP4uS4qgsGGVdBwYkUpNZOLFwWivMVhVO6GTqkMSgxKCkg9IPMpARoN1MRWBi xAMqAhUrpOp6gG1wtsHZBl9L92YakLqrFAj1VWkr5i6hdFpmFjbdFptuhRtI61pcFp8caKn68gFC CyKF1rer1b81KI5CXIf9xaKTkZ2RnT06ckkcbNPKd9q/VS5oGtltOn8j8c8fUmjg+CqQtuZNiS0a Fqlm4lIaY+W40NpBWvRO6lVuhoxk1IOsTIi9OfbmqiM2e3NrefIm9uZ0hMr+s3xLgVtmlbVYZUVI FKJYeVeX0XGr3W73gH6dt3S/JrqMzJcLTO9jtcORE7tKHbdmZa7w6ItQ7o0ay1h8xWqiq3DsBLrh cXcSxIt/5cMaARWQ+WKtVPUI66hqr0yElAgpEdI1EdLdnYajowNySEpgvqpYVP4zRilGKaJ9RPve He3rkljSeGJJSaQqopqURyj9EyH2rLqcmB8xv+q4TcyPmJ/W1C9xQRnWh2qq6fVUsX3INhn8Ktcf miPbZFDONikee2Bkr45jREmJkhIlXRMlBaiFyE62iSDbpCIHzNkmoEWSapITvfxZFaneHmW1LINw cyI3J74HFTJnmpDQ/4oSi1STQso+4VFOh3M6/MNIYU2kRO6ygBLih5397kqMm4Yx9avbdcU/JdRH qI9UE1JN3p1q0iPVhJGqrNO7LtmEUYpRilGKUeoDotRKhQSFTRZYFBy5Wxy5WzCSlg5tWBFaLGxi SvYisokQ+ySR6n6oM8RYpSEVWO0tUk1INSHV5BVUkx6RUtSfFDYppxtrqkkWl0rJJlPMlFGK9Sfr T9af71p/7u70rdS3QNek/qsHflvFBHUtoQanoSdd8e138d0yM9S93E6G3komqO1R+L6AQjRNP+a/ Mh1hOsJ0hOnIu6Yjej6jz6atEExJXPF/fi/cPTEfiKZ/ZkBiQGJAYkD6gIDE/qx/FE8cVx63JpGM ZfQgW1pvbaVqqb59a0oBzCq0rtEfKe7P/pYhEQj7c2UoIzsjOyM7I/sHRHZKAbA/awYEi+WOzEKk l7hU1qO18iBK0FGCrjpeU4KOEnQV8iNTFYDsq+VbmteefVTJ3SomqGtPriQuLTNJ3Vu1rxHha4ZC xBQOX/6VZXV1mCbtmbRn0p7XgPUwIQlQ+Fq6aaSSJ3EaYj+Th93xemV8PIfplbknOiU6JWJ9xPre Eevbh1P6cvL15HUOSTsqOiU6JTolOqV3dEoH8Con7n0QPvrSuzVrjOP5vmdZjpQ9LsSBhQIQdybu XO2miTsTd67EnQ/hlK7kSEYycLFtd8WSbdZN0SlVX0FiSsSUiCmthSkJcciJACG+htEYSNqDtJK+ koZgw7ph0Zoxi1GKUYr1/J9Qz7MmZU1a7WpYk76qJuXF4sXixXrMTBD/cRpPheu67ewxf02sVl+o y2igk+uJJgRP8IIR2tdXx612u91D3X6u12iYhy6jggfP5MhJ/WTxJ5czD5lX1v+MEduL86/T926J 7h129pb8gg963epndPf7B9XP4CavY9uPcJPXx23yKlQmrfF04GUUpnGyJWQiHH+HZfv8AOkLz/n8 20RhrlRcyGGUOtGT6OxuiW67s/vyFPPdb5d6IWP3d8uW9Ni2CyPETIj5XSBmXixerOr0kcX7q4p3 lBGFpYQuB6KsOoguwiDRRY0Tu0odt05DcGrz1AyPSidOTmLlHLdu1BiB86t8FFfh2Al0jXJ3At7t wl/5sBV4peK2X4JERoFMts8iZ5TkodwK3QXdCw6uLEr6N+K0CCf1VChcrUYZm7nbph8Vpe9POFnJ DA1r+E3rgpP0FiWWLhVsGVumLkxdmLoQHv1UhbASHrWdRKfd3l+GObcPD5eAzqwJXlUTrB6xdi+6 Z+3Pz80I9h1K9xbt9TtLDut+r7ukQ3LQ7ferIwkaNXnPqWx/Ei/Wv6As1Rcqr6WbUGybjHiuVJir Gw93988Pz1sbizIMDnfeKMS56RYoFgMBab/6F59HjM39xX8JsCfp7ezXTbdD8a9frMd+fT33lYnH 0SSMj1u7/cMlaTITD9OAsvgsnd5+f1me1N/bNZZF7EYuZegxm4eHlyYeNXU/mGNNk7swiv9NnHge 2vjx+qNjmPGwQhirIbs0Z0+fPf0/uafPaM9oX7IPutMFKlINijDab3q0H3RQV6KFH4Ve6moFLwbo jLUNNGkxu2WAZoD+kwP03FAC+wDsA8A1GYSCAdoM8hjsoLQcrycYjD6AFahrxzUcnMRCBZ5ynUR6 +E789mV77hMvDJrUnVR4tqNkMlrJCnUlig0afwiixH2Uw4YfgvABy+mUfPx9S6hE3DmxGEoZCCdI lKsm2mVYBlodZ2S2RTiEcMgv15rJ8TJ9sCDkVJpt5fdnY3vQJb3XhWxrIfe4jZxxjYdckzsnsVxq wUyHNkFd846Sc7HMJHXPSLmfJSk5GY/K90UQJqBtjB2UL04gVBz6WTUTQ7bCw0Oe0PdKxOFYzpdz Cw6GR2l+YopZHbvHS9pTncP2EuIvMbQVMDRmddk5m2PabrpZBjLwJiHmD+NleUwDU7ssgEuAj4ke Vx2P08CAkUKvKhSefFBaOzuNM3QyTO5kZFmR0YnRidHpA2YTa9fqKKkgGo85yG8qTlRwa7lV4g6y NRCQ23gMo3soh+hghNgj7qQ/EeFIOOIWNeaj8wRazw1iksRIhQRKHogwwpI+BDPLnIxSjFKMUoxS S/D+UvGfRR7CAnBVc2R87HxTY/UH9zXEC8KPOi6BqBSrofL1plgUUjLGxI+v4ixoYYQkBuXURLEw TUwgC1ByMUSRg/pMcqMWRaSF37Io/Z4a2CykENaedFeh5iEKJYDlUVlD6RoqE6JLIieIoUaHOtNw iVSMjp2G+4CNkniYSdgPSDxMSDwk8RCHwDgNCpNX6a1xRoozUu8yI8X8tCH56RwmzfRUp6cqcP3U kxq51zhKOMK+ZmHazCJOlUZRpK2lbKhkTmQDUcT3ie8T3yd4Qnxfp6zrbotD/B04D47ytbclhLII 8IcmNg2j8DGWkek4Az/xQjcFfJIItIIelAeWlCE436b43lcB/vxqlQmOZ3E8i+NZjR3P8rEP50oD s5H09I64z5F07jPxd5KoWgtTejp8oXZg4FoIXM8VVL6HBp3poQTLFxuVzOHiYhocHQ53lQ13ub5C fhNrQoOTaWFad4xFN4tuFt0sull0v7boZtbiHy3y6cYhlqBF0pcPEDoBMGz2xsnIyel1mEUSrgNO nb2EmtGI0YjR6AOiUeHFOj3dO+u0teePUEtcLco1apeYb6yZit/jK56/qDaKlUNLfnEHvSWbj7j8 zL783NGkj+afvDpYX5Rm7WhaXg5+3t87Pz8t8hMHe/t680juQS6PW+127lToOor9JNe7FQSPTt22 rOjTv3lrYoDBlkLT85o/0TRr0Hd+b2//sHO4wWvcbsBayeBVyxvOsLr0x8z9YN1+uTNQsiHwzLZF q8yx6b/14rMOVpLFqs/g9io7nPT6excbvMSw2A5xOpmEkRY01tpfOcPLqBu/ULyqrFLP0xEG/lOl K+yc7O8edjbYFc5rNluO/vx89xRl3MZ6wMHCdJH18ep5k+fP68LUc6lcXy1i+5tag3WwQLF/F9PG ICbuxOOdcu8WUVqj2JHxeKtcfe+if9Zrb65XKDYQuBuYCNeKY/MXyPIZM/VujTL+PPpj0lCz5gDW xw50P3MGQtVZ2PSwP0D2q8f65wb7m1EJ+OpeGjrJc3sG4nGxG6lhNl4aS7N2Kxa7O52d7ha+dHe6 Jj/c3ektbMKONjdNWKErlTu9aRk8A57bPyEoxtXDi+2Sxi0jLGxA2TdltgFl/4R3iHeId0hjypsb Un9GHhlpDdqM9yHGzpP4RwrRxBHElqoyynoW5QCctS2qPvimQ0nFZRV0H6s+dD1/28tr6Hr+ssE4 VnpRr+M38JeeVcs74gv4b+Bf48ZrGhzYcLgCyd1slwU9BhU84Edh9GTKqeextKqr0uv2Drsb3HUr 9g8OdpFoW8198vVAy003zdvmGTRoWU8/+sIonTseNiR31u8fntYNjzTuZP5aWJ9703/ngwWasAqA To8dHUKMX8TgUzrxzGIix3WhEg2A0n+qOgsb7wlWgKL2ztvnJxetKRR1GWkHUD5+bD+dtTVra9bW 2oVMdHE9md4i0/l788XK75p55YxWSiL1KNGuymyFJxuy9mxIXiyb1U/JQUoOmnjbbWcDM+sK/Uwn FAov1lzWtywVtJ9uUsH8IUasIYLUYmLEiFVglHrx93mxGLGWzDJyV+vUOcpgu7EST8mgq3XkZDRW QeiHtzYQRTdCN0I38mfNstuZ7BUTXzkDs+zqId1Me65kfJ8Y6GKq3ziO3gzJ2bo/G0s6Ku4wYw/g Fy1UPtOB3zIt53v5JLCq1ItF66dfrm9aW9lX8fVn8/3V+f/+5cvV+Vlry2o4Mc4zzlc71w7LBZYL VcP1reu/nfz4o/Y35pupw7n+28+//Ah3ox/W300fvzo//fmnn86/nmlfBB918n/pkiqzG2LuxNzf BXNvToZkpTjo1kZhODqPNN2oEWsooXmwigXOAy8L/dowRkSt1olz6+fLmy8/fz35sSW0TEYmjWFI W5NIGqkIbFSYHRi8ujgVXaQ/li2ZMDNhZsL8AcBYc6LTb3As2q/8vgI7ksggaG1lsp1EBp2F1Lh7 0O0v8U+9/X7O3igzLFviOh06k7Buu727v39YLCBpX04SUIjDvzcOjz1eyM2Vd9zqa9qpkyZ3IQjy 18l//9fkzgmkuIxCjKHqn+nBguNWt93pb3fa2+3Dm87BUbuN//3PPMm/CLUaDF4kdpU6bp2GaaQw 1PpVPuq/LrHx5yRWznHrRo2xOQwPi6tw7AT6h/8yGduXz7/7hs9vWgD4GIs1Tv6gfdM3tWMAY93I b8mgh74+FD1UYKYXY12+TH+kv8cYdvaI+brIG7e9WmEz0rbX1LIzKiL2a9Az0jN+nGc0Cs4N84yv RSF4cX1SCyq7DZ2PLiAQihAwdEqz/4aQbj5DtNkpzcEbPn+zUppSKsSP8tZxn6B5l4D6cB8fvXAj ImeUbAnf/rmQgRuOJ05sFA2YGOlTVIYB9Pb2lgAJbEwuoC9/Aa7Ei389fIN/qYN/zbYDvTIzpINt DcA1g7z+g4xiI2IAHZypowXjzElMG83xsRrYe0LnbOKHT1DaNDKcWgPl8vrmq6Gm0c/SzyLlMzPT 9VkL9eJnO52mO9ruGwxAR2sc7eWPP2XeUnz56XpL/G0H2i/P7tY0CnHgDLz3ThjerGAp4Tqb1EC4 7r3hug0s1V+Lsc1erNPd3f1zg3Po3gNxcF4sXixgDirQjUiNAXZ666UOnfZNp3+02zF9TZM6mP+X L73cHDwQuMugpyN5YrpwWU8OZtGfZiazXLPru2idaW+uQFTNInvmzzvLKA+529pU004zpX5F5TlD N1tmm001Q8k+RHSHr/J6PtuXUa5zu0Ccrly2ZGeRduN4Y234djHTWpqlBJEvWEP5HmmUbUKmUUyj mEbp2PYq8s5sfcKLxcKffGHkgrqA0BcqLySmabOVI29sDlMSrKH+gzYNKJ6gjmrtfjWe+HIMIf9M shpC/z9f/nIt9LjC3n5n73fI/M8reK+eINbDkm/LButhg5LTNN3I6TrBfF3LMDUjZ0PWxF+RNbGB +PQMglFrxyKWBp3byBlfJ06U1HKceXCbOpGD5TvS8qslY+0NG+rWRJNst8jC+o3v9ALoME1EAuvF eBLWbXwvQFvB37EsyULKLoIYoRihDL7yVpFvRij0d54mGMureYSKUTLaPpXRSYLWY3blSfAkE/EQ KleKf6aOr5In8d1QJgmGL0GjDETgRFH4KIYoxEVLsyZbDE8VxHSGJ4YnhqdRtH1xpesdZK8GvUSo KUFmGl9A5V7X8qoMUAhQ38+X1jPUk1cM3LePelpz4D+z5ZWFGLrNM9m96J61P2dP30AKT84zKb52 YeA/GfNO2Sjmppr7ikdML6HQQjXrMiDReZSSjYNf5fDq5nSZCzL8moZBOHnjQC+jeMvm5HpgoGww laYxiXTvsk0l2EhuXSQCeATwlmie/QUGc9li+hfLSrFC0vJeRYXj4C58lJjztbwqKyQN4clvE+lq dWDoBc+ZZ2aK4RUaRO2jfqbOZpUCRnBws6uiEhhiKEUaw46WERG5F4ceXqELU2xMKyVsTuV55zyA 1hVC4xpqcDLwYPQ0dm5lo6rRAe4rtF7GaaBcNCeEbgbPH71X8ZLOshGZ3sFuZ8/MPRtVwWrtu4vd bu9k3+AcOcMQqitm1qdMfeWws2TnVeeg163Oebr7/YPqZ1Di5dhOnDvtw8MlVv0rrMMBfgRvZsbn 1tSQ0gNiu0ft/Q2XBY2agJxBfcVyWCX5WI2JTyGYOsxJ44njgkKAJRWxjB50Tqo5BbFuLufQ2dwx mclL15SAgntoHxx1e4sgvs5Le32Esd2NRetL8lLkRiCG2VftJS19sSXIMPA666lJIS2dmVSeOq06 5PgDczfFMyan5AIklyf2jfDVO/b5mZ3h7q6pDmSFaKs2rChn8mx0U3tHeYusuJHWrLLlSyIwQSGm 1fIojDB2A35V4M4TrGZc05r6S+VHzLj5rLLZ1LM0jHJShGm1NskJzfugmQPyCpWN5zLB8kE1OCBl eYBtvpcUoGYBbODEAg7GcV0Z2zF7VpcFQ6FrZTu1dillJ8bKu6cHBl/fgiudnXb65yfa+CvgSgen e53+KXGlkr3w+73uEgQMy5KWiBwDiFu2LKnd3l8G1m0artRdk/2lr//eEZSZ6rJuprtmR6fc/zU1 a8/Qqzyzz2iqs+S3hcnxmo9IPFfKT1bUKAH1GkYBQ6+m98PlpZY+FRrkwqhEbKdjVm6yZoPQck4L 2excwM2ua/7gptZAJQnLd3LndgGpWLiIlRpftbTW4O/hjzfny+5lCTdTV0S1tEoxGrM1fy95fpLB 3xXPz4rTKHMjB9OqqXajogMAd0k451NmEJlXNG6fE+yyGLap4YqQHa5BpH97Mwdk/dbdSwVWtwNS ks/MNcjr60tetC1yJpMYqW+gdYXz3fGX89Nbs125UpK8qQ6m7PxY7nl6fPD1TwPwcv1FbVcSwxY1 PQngHS0apWI5+wsxrPeKrjPyCzR9arIvGuzItRsYxQlWBYC34TBBddudAJ4OD9PZ+sE4HCp/vge/ UPxqFLNh4J0VRGdT2N6aXed8Z323SeyzUxW5qUpsUGWaiVjGXL8hW2Mq3+DaOnWFBluzhVV9+nb3 9w/Ps05r7hE2aJyvdPANQxHunakjyg5gzcgPxZjm38Mvl7YBZgl8vTVbgflBKiDRVmQSG36+KjOJ fAnz385yESx9dUv7gjU7cIO8nWW5K8uvr9nMKj9dhla84W5qEJv9sZa1Cp376+DTrLypGzpm4NNS H287tkJjrgk11vsIFoeI5Vbsvw5wq+eRXAtwm3WH/TVxiyaexawSXeFErgmB5LbMSFwLTnLDM5SS E2loJ0vDTf91lWxBCliLIN374VP3B3G63Gxr1qz1PoCDrNRfbrU1C9e8c8NAYvVP+6+r2mrq/AbX eam//PSxHkGOPEV9S5LBTMwZDI+z89MbCDdrXRMDIiTSl5O7MLBJni9Jd92q2x3rPFmJHCu0l3PU YIKLnaZaJ2TNspNxrr5+5DQMYvnPFLvn/Kct4YhY3QZqBOWeICn1MLssuF88TEl5Y9++6fnBVzJc 9pYMfnHNwF9xzQD6BqB1aOmj3TWRIit8YEQcSd5FGCSxZonErlLHrdMwjRSWcnyVj5o7Ip04OYm1 ZOKNGv+LpSv1jc0E0mcMsCa8YxnAgncq+lJkuEQ6Z2/EFp8gHQ+pt3S0qLeklZYc38fcPDQVfXUv oeyPkbXQddMISh1G4L48TVkTOyy/pjOTRub6buDGhAYXQuUHZE2UtNYHpCyPLU5kEcPhnI1QghXD NvV6JAMsBRurwIGvidPJJIwSaJOVnxwixayAhrgBiyRxir/OK7vWT6Rjd80WhxU4alEBrdmrsAzA CghKouty/Eu1AWoSfrmlqSwBy6VmIR2GsUOtywvtz2mqoksiCM4XzEe8zCPush/0kqssYeyVzrXO gD/v1jyxbm6eTZ9lGve1Bn90Vg173mBHwqI6Ud3KCqwZ9mKZxFv54LBuVpeWFRA8wzlYXem4PKzW ALEo84eW9XCU4OnMMWJjhY0VX44SfYUmYXzc2ridEntNb6xka13ew/81NbauW1bUXvsvz5StoAH/ EIXh6HyuwdSs6eGtjEL3Ukskd04ivFAEYTKFQG3st8BsrEonWBBi69O9VF57bECtXnlZN3Sa1tWu zVBCa53W+EGFrhCyOxYHy/jBhacIp4nFAYuDDS8O3tJyrEPPYe8tTRf2HHTPQXvHpiBvJZHWChAF GW3NCyI1nvhyDLb3KnZoVkEkfr785XpHiBOwzbDANqfFu3JLoOkSyyIi2pwRZzL/d+uP1gDIfXvP Ze/dWlhNxYWa5PkHw3mxuJmL+W7duxpczD+lw3JVvaCbOqwmNy/bRk4d1gKKXYUO64ZPluy/WwO4 qYFuSZFTCPzXeJG3VNzkPfaLJ0v88FEEThThy1CTqy6vb76Kf6aOr5KnfDf1Dzv7nY5AX2QI5pWQ oHLMK7+/FltkWMRslzMEor1Iod7rd7othkUbr+ztQ+es0ij1Cou8WDaPnlPRf8Wp6A3MN3mxeLGW BJLOYXvJ+t5OFwt8l7wKIxYWFOb4BvKcxWHJ6YNESJgK4ixkpFVeLI1VGxk4HamyUfumle2XUZjG yZaQiXD8eam3QmM0rFeH+bnsv/NvExVBI+ZCDqPUiZ5EZ3dLdNud3ekT8q+/XTq3UvR+t1p2TIWY Ci1JYpgKTSEaGWz/cq0piC/yTKNo214+O/XYvFi8WLxYj5kJ4j9OtdaZwTm7OYbnO8Ht9LF1LlZD CNFfAswlBDLZPoucUZKHcCt0F1C3OIywOIwQ4ZAtFp4bq9JTQupzUk+F4Gx50o3FCOrQTT8q+dri lczQ0MrhJL1FiaVLhb5lJqYuTF2YunxA6sKLxYvFi8WLVclhoHqe7SQ67bqo521gp7whxTbKaysD Liitaz4V5YxG0k2kt4oZGlYuDSG4HTlBjOIagrginMjISRSmozApdXMnhRc5j0PHvQcxcgTZCPfO siFzPtudk8RFEhdx4IW2UfkK5caHphnna3nWkiDdsOj0Eo7MhohI6m0RWAk4lCD3H1kGYyhiKCL8 QPiB8IPmcBiu4WEHgrOV9iD8oI11dxLEi1vKXEiMzi4uM4Z8z14/IxYj1pLrSXYaSTSPRz72JV7J wJOR9DTN9XMknfvMr5cQJhpfVoVCnEmgmh5Bv4Lh6DTGlgn5DVifkoErBVbY3wmwrCdASfX+vWwL ez4qfZT9kcUWFpuWTTQT9yPuR9xvLdyPXancv1qOlbCfhJClwpLGlz312Anr5bFc2O0q9KguwAaF /FfiII5tWaZkecXyiuXVBwCCzaFNMEZBXcpyqoxPOj5l4cjwJHSscjDNC32p9k5XF0/tnZ746edr M6cwDkFBB3GirMvHGMUYxRjFGLVk7LaKP8EYBTSLMWriuNhUNAGIJ6MHHaNcJ4ZsgkH2Tn662v71 s5Y57HR39naXskHrPmh5P1RL9fHtnU81G7McfELSgoxFBVr7XsTOWAqQQCGggeFK6y4xQWGCwgSF CQoTlFcKOyB1G5it7pZbZRmtU5RH5UmjzDxTHmd5C4DdL9hSeRemviZ7ijhBYhOD+GmWWKqRZUzG KMYoxijGqLfFqEwKHmgeyklPOHpJ1Ahkc0jHu/eZ9IhB9HLljXxKauvZh9EjkR4x5d1uyGJ6TuwC IPkqH8VVOHYC7T3+ZCIwYb3kJFbOcauIODIwJDTLrTJr1lnzdIPJo9LRSQofPSbky9eYzTV7TpBV Gzafl7p6kFdIM/yMze+PgWVNps1Mm5k2M21+W9psuZQSB13j/VtJuIoBGja1O7t0y/WlE70w+GLT cDD8c7DPXakeUGxNI1pIXEcrd5Jknm1KaB8eLlkT1uF8FOejWEVVVVGaDqBcEiTiBYIEApORPAJl D42GCILUpifuo9EgRpH8ZyqDJFsKP62uHBGDT0EJpMqRco5CcRSKo1BFiFbprC4pfCyjCqZ0nztS JiSh8x2AeB6ryBn6EmuKheO6coJiAX9y70IEebK3lqwsZGxibGJsYmwyZ2CVtTyaveVijUQ4llHc ZKRvoBlZ1hyTHnwChAfC8NgI8iWPUgbi58tfrk0Z5QRPYpH3xp4Te07sObHnxJ7TG+jEU9psk+NR SS1tVoS9kPLA2xuP00C52aiuO6UTjx3Q+PB/OnCl9igQIxQjFCMUIxQj1JsiVGLviSghhjSMF/Gs YjQlPHyndSKwekMvOLdVIkDsywqqbHbXCvUMUQxRDFEMUW8LUUYKQE/C57PgBrmx/EyJ064vm6+4 qNCyCXvUTKBmQqz1EoYANYWnsInEbMla5cI0LMtxIpttxHSF6QrTFaYrb0tXVnG09c1MBpYc7iq2 aFjQwTow8DcNRya5C2PwY0ZiTvYqz3VBnMmalMR9OWygfRKHDT50yxHVgqMIpyx5mkCfr957lovr ZxbPAwoOfoq/32HasjCDIi7SCAqM0RgtgC0NLzy3CNww8JSBGLbMyKTjZX9EYmPZkdU1q2tW16yu WV2/oV/tyRHw3GYTfLeEr+6lcFJPhdhokKiRA5MIL5V6qQEi171MtNYMVKW3DMNXKwebZzMecWif dfRHbwtmHd2YOnqQSXY1Oh4VYwl6SWnqJyq4xYh+ODaVERYduNkkPzBfT0HtLNKT+zMRiwGKAYoB igEKZ2Cdyb8SF4Rp/cav1wb9JXyQ0ZPlWUv4Yg3rRDr+bRhhn/Y4FmPnKQ9YGtpznnXOhhLtygzV ex7htyxJUI+gHkE9gnoE9d4A6vlqvHzNl27INixAYWI/q5umugZ2Y46xh7GHsecDYg8vFi8WLxYv VqV6Zne/f1B9SHp7e1Q5k6OE1E2XiN57IXoW+lKCY9V4uiAU4kyiFPKkt4olGlYwmW0F8hvEzpQM oLJpdmqjETUBZ0RzI0DVAxYaG40Zx7cMyJyPOV91OOcKg9t1nLi+UJeRHlzRpPooVt7VZXTcarfb PYi7nrfMT/InXIQBCEyPR+gPK3Xcmp1ywKPSiXPd/Bs15iI4hfEp7MKzEce/hGUGZuUmyGjqQSWN 7jgNjgxwl3HEM0kzUB7s8INOEzYZTK0FkU7GI5If4O445Tbr/00NHv9xqsMDBaEpCL0OLWQASrTl VEvqxYZVSSiENCNcBW6E1MoMYMvA0/WR/uI7CWqnJ7NCe05CBX/N4Sw2Z7EJ6BHQW6sW5OK3qsVv c5k/g5TenY3iKAqxGFsLPz+ZeJVETgAFTrMJLgTEZ8qqGNsObmZ+oLfBQfKLtRSjFKMUoxSj1NF7 1M56uc4o9e2OCeOUjlOe3F5WYqL95Ps17klm81vqDxOQVzJGwwpuzeP0MIeRpS7YzYTqG6uYFLbU JijBx+I71OI+xrmDW8t87EmyJ8me5Afw0NiTbM6E9li62Meq4rFdEzJ70dmLnsOW2/9Qid6pPkz1 RLae2HaAA89MZWM0Lhsi/F6HroAxin1K9ilJ6Zx2ZFdcz8ohbeUct4o6uINIbqPnZuoDy7k2LEgN thBpWE4bAS+W00dJicfQ2QnOSYxuNZIV3QBAPe1J33nCnuO8aWBdI9bRrKNZR7OOtimzRZG4xONQ SCYZDBtN6C05GI7v65JYk6ieO9KQ5ITcphGBfsA3CFZaXeaZbaXB34xuxRjFOpp1NOto1tHv1aOG X7WcasPq55IgZUojrCl+wqIC4TzrmEFFGrI7cSYmbSYl9W4DhDMnEJ2YMYrj+8d22dhpHx52WUex jmId9QaxM8Yo/yhGcxE7tiYg6sroQTci86kTCpyRt0ve7ofzdgmI25kNBAlyj544w2k55s9KF+32 D/eqU5+9fmdJcrTf6y5RjDro9pcoRh129pa80067vb/krTKRyyUU3n24mBeLF6vaTVBFZq2ZDH2h mqUiswqAVeNhAgicneQLNOcUugjm6ULJDWNgdlhSEMjkMYzuYyjNzMw/TnxUVvj5eBJGiRNwWp/1 FOupD6+nOE/QnHmC6XpnRqcCGC+LTuFzdBK3UJN51MS8saMCXy/Z0UifEZsB31W6VrbD6onVE6un D+kvDcPwfuxE96ZyAMKlvOPWfkenBoEzBhT//34IP4N3nFl/+uRz9Iufn2qwkgh/ppTn0wQW0/to alyHoYLw5RjrOVea6q7zch5MJZhQpZkSrgxiuQWy+cQPn7R1sGE7kXGSD80xmpHRBw9JBU8qeK6j U1nC2yLrPBnAjMprfAgqOSCm2sL805dEjLEiDhQ/EYSmuoJOpwULYs77UXlyCDY6YxRjFGMUWec4 A4xRb1YV18poSWj5VPapdJ9qGm7EY5j6el7X6HIKQzE/vfzFzEUhXpk/6zgGbNAwz4doa0lqjFSu niNdyZ+npncO20u4VZ0u2FVL0MXefn8Zu6q/t2vYVcCqwRWLdXsx+qtssXlZlLMw29o8HgWqp2Vu eV6YEeIB4f9n7+t2Gse2rV/F4qpbKug4PyRwRCQKqNpIu3rzQbr7aJfqwiQrxGrHTtsOFPvqPM0n 7efYb3Ke5Iy5bCdesR3bSagq27PVaiAEmsysNX/GHHPM6U2lW1lbjgCFKttwXeclUQakhCxpGwDA wY1JtczquxVAhbfbJbO+QofKY046cyiYQ1GWQ7HlwkWxiNu93O7NScg4rUOZzldpI9vnydwNg/BA R8GBDr5KGyeHr9KGQfgq8VUKkXFlALDd7+YATHyV+CoFa5m5VtoKX/NVUus+ntgleGV2aXvJ3e98 lfgqrcA3Hn53tV+DELMuZEbmHAN/eFi7d+aGzVcpIjYo6Zs+6OSoM3BU4qj0VlepMNEmgsYrMVC4 9kGJdjN6jek9tTvXAVPxnSZ8zbBAXYz+2WjVurjENZozGd58XdBWWu2DeHSXhvuq6b13Wrul96LX H378fGc8Ca37RTEH90lUz8T0F6a/SI/a3lGGL/KyfLH4YnED8k3mTWsWwNOTmVsba/Ogw3J87RpT PwzhSujOIlbVeHD0D/F4P7oqZIUqEcgKp/CZqa9mYMOvE82S0k7gQkaq8VEx6f44i0JmaNhZieqC y+UTTXahVOgqZuLUhVMXTl3eIHXhi8UXiy/WD3qxrnq9/k2fWhwEDt5dHLVarQ7goJsjoqiHQqHR WE6WlDO6SDlvMPcKlN4Jt92+ZdutcKERoVhQaLJpjlVKOrXpchhLf+a4F0cP/n/+vcA6H6EFsDt9 D2IKEC+ifPJYb+Hfkd497+nnrdY/5R1yf6iBtsK2oNmmRIIMs9CrwfqjyDqdfa2DXyTbEjHPEz10 B4Ov3FH44LUAUttqhW6rqqaFAUfiqz/sUQUSfUGf47AEj8hXFhkiaYZ7xTZVNUNGRwtNrLVgseYt TcQdSxykzK+tJYflQSLydnRyFkWPWfS8azE1lpaftCWnD7yyQgYYJdnRKz4DXjhk0oWiwXW+WFzw 5tRDPIWHYFL6YiE/imJQnfMfINUjrLSeOpblvJAOZiiWSVuwxw44vRPhQvDZ8Ej7WTxjJ0EiSaLl o+SHfOmN2CcZm/wOZrxsWoTX6PAaHVQDGTUZfJLiT5DqVF/apXAAIkcKsuFCjNX1LxlWaFhn1Xcg NCa0J2EL17C0xdKFXK+ApLM3ds1HRCrs1vFgOhNbDLoo7kczk5SfPdWWnDVz1sxZ8xu0iZqTNTc+ Qk0tuFmviBmaFqIQn8ZL18V+Ac3DAoalp0HAOc9Qm2p2Nas+d8CMm+JLwCXEInVha0skMmPDE14g Co7EBXrgyrnhvIXzFs5bOG+hRvgu83tcWVvmHC1e33wWimPl4ppUv7FfQnMWKK3lhr/p0kWp7aKi HltLjwpqpDGOfCgEiYkF/zIzx+XhX27rkv501JdQWpjc1j10WzdGsOqS5yxOsGqdjfTT815HEqyC FXofHKwNo1/ijc2k4MnaKb+ZsENhIJGSRV6+Xm1B8MJvdoAaBx06jmwLrFG/OFpQXeU+U2RblVYo sGzatIS+pu2bU1NMCgiED96fXvavyHVI+mAseH3otTuXKqU5fLJkOwXXjynNU5+MJxfr9TvtHCU+ LHrI2fTQJEpzLHj1dgpevYoHr5gBTssZgOjRp+f6oAb06PQJ5s1yDhE/ZE3HjCa9044pT4IZHHNu P8zelDIxMt2OYMAAeluvho+TYFwxdubYFTsJiiKEDiW8ppp8UO6chllmd31Oo0hDtNeN4BOQkar+ PgxlUTnZLMLdlBdeWcL5UDajqVvtTKeyjs4/OWflTk59PNyji/IKlymgjyW82KBVzjCFrlRlT1a6 F8t3TAO5Mr54LKjP8cpkGuVeyUHJmawmnrwocmpg5/zj7reHAidxt1mu0/QQefWhfd2/PqrZfSY0 9uNJX9cLmHM3XGt7xlFZcw6N8dhxJ8RmVtunMrzgPz/Kxr8ymeswIL6tmsWh+gpYcI+mZfqv+Y6s ZPlYH+cvc4vCbNO0jH5QsvJsYhCQzAWKAEVKpMFuVWmAZUjHVKtKAQEUWKUnJvm3+C1qy8p6+vRE +CQ9YOJiJ2dQU6vrUJUiOmIxvFd9upxBjZXiLGEhI5rSzmS8N5g9U4yi/8h7iAtnJXSheAY1eeR5 3ovnveSp+BEUjll0SaWMMr0m6bAap5oQF10a7IC510N0yTI8/546W5jwps0F711h/BksLCogx3RW EpInPEG1W5RfJ8VdVMmh8Hksx1SrpRonOmkvfbo//uP9ZtWbLNM2KjJFkSE6RrEyTX06SwVx0OOg R5ds74vF2SRnk+0cdl4Ds8k8fYo1Hetshxa8mjVVFqwtklOWbLZzTgm+zFrVs+kSn0PklLrK50bM S9OOSY6k5xUhlb126T2SKPXWPoZKKoGCyoKEUzgdJ22ijPEsBncZ3P1hwF2uczkd53Q8ZHRF7Uh8 GUFCCk5UuwgulTsvJwaC9rPQPkEm2zy+x4IAlf6QkgHVXmsG033vQZ9UEpksOyRTwVqfmp8CyPVn DfIyhtb5eHcH8bypSTP/OBZih1l+xVzRzWMwNjODZDCWwVgUGE0JUnlO+Mk15jXekimlUorYoGFx yJ8ZPsWgOeK04TvuK1GHzfnCEhi2xHdsqNG8BvEJa0bnpg21V/oZxZSHaGlwDcU1FNdQja2hFH+S UiPUPDx5y8XCcVnH9dxLaMa8oIp8pCG8oC6CKMB8vrTNMdTjHHsl0fkoaM4M+jJy2ntsumPsEFMO FQcpNcAwgs4I+kEQdK6h0KZ6XUDpqu5BCiuGxrON6biMWN2wMmruYPxXaD6WMy1mDiomUjwzxwLg HiKXLV60OeHCczExjfWzOD5xhxdIrRRk01tnZ20WlWZRaVLYWeuXTt3jD/d0LJC+hoIJmSIquQ2n usen0OcqbpXjEwlvOs9Qvrq9++X204OMSN2Pv+RZqe7dyd+dv49uChmhrrnM8B3V1GMpv6o9vmof Hz5d0orJZweZi4ajoliH62eunzk/4fyE8xNiMFkG4MYS+4xJGBwU6CmqRMWrcnpC6QltsMgzC+cj QJikEeqaj2RQ5NGD/nx7f3LW/gK0/xO2dIEp5Ru4SAT14+TMZSdAw2IUHmM9Pc2ZCmPUn1F/Rv0Z Vbk4Evbxbw/5ydwQmzryQjPhSg0LSlBXnDpLYPthdOqcUnSiOIXPgl1dGOXSXAHJcWFTI4ByHMOy JJdKMSgX1lxYc2HNhXW+L85IkFdDpK6wMHcimTKE6gUUGS/0RsSPWSXOkg6LL72xa/KwKSfNqiwm tyJd7VfBHmkPj6RkOBkgV43HDQpMvTUwaX5wli46SxR8VHkIToE5BeYU+A0CziEuFouNqZeTB0d5 cBQdwFRBo1hKExMb223Lkr7eslRZzYQiYmMllyax2BiLjSGsRWRIEhtrq9lkxt1MItSNExvLq8oy e+y1tdTwD/F4P7oqZBg+QAAYxbOBufBokbvsanDbndvuaorMwwygW78JgniIgo6lFtTTygUdF3QN UgIaYRX63HD/FD42oodk/4VwPYe0XZTpehKGmbhQtbNpPCCYcVQyJfZGqidhdh2z65hdx+y64uy6 SFTLU/xqYQRDEX2sLkq4WkFEEcd2XtYKZIGey5xY35Ads7V2qwXaSjBaP0cf0VINxwGJAxI3Et+g kcgiLw0ReWHmipUiQjboaX+7DisgyLn4L477JxErtdMWSqal7bsmKN7Qx5lBzXm89HxnDgTo0fAE aiwltHOE4gjFEYojFHMrdx2jpmJAcakNq5YypgBkeaSjPJqblhVIY15qM/NpptnL+SOiEcC+MQaQ IEmGYmrs2J74awmNZ+tVMSbHJ45PHJ84PnF82jU+WeafYsOpcoQilQ9sFnDG4yXqIhRQAk0lJfCk 2CiTjlQT2HMv7lE9bJCRzIwtE6lJoJ4aaqvKHUkruFxl/HHSwkkLJy2ctOyRtBArgliNqJICPiNR HjhA7UGObUSAenGW1kSppknkw3lRTg6HJw5PHJ44PO0RnhR/klIq1Vza23cN28PcOERMilgiOalR 62A0dYVAMxLFkQMiZyCHGPQioTcVL5+iXUqKDTk6cXTi6MTRiaPTrohvhEopbjUjSDcrNIHY+V54 2ODnveNiep9J01rnLxHa6y5tm2TqIOW8WqgV7Bxmli/5Jt94jDTnFcE2HjvhsRMeOyk1dvJTkVgd U3NxcfFcBLL7ejjioYcJQJ9WFQrVtTYsaxn+jFHIV8g0E/TvowUQYv+BPqphucKYvCrTKIhNeJ6n MtC4hOYSmktoLqG5hN61hA5n+opE5bpW0EPmtHCRQx6E9wFfQSjY/JEldFgTVU34WEKHJXTKaaL2 yNMZS3/muBdHD/5//r3AeL/Q7lwH05P0vQlWWVwctVt691hv4d+R3j3vNUUT9XRf60RwRZ5wY/i8 awEErdUK3RqF4VBf0/3gEA8Xb5U3Ns2Lo7hnxqPrReUjc44JWGieaffO3LDp759d2l7yR8ae+luw 2/zl3PvXFf1P9gKxcGSENRJf/WGP0sjoC/ociqnBI/KV4X8koZw821TVDD5ponbUbLIwrlNbo2Qw zbWPS7SnLBNAWEzMElRQ40nIVenmfGGJOdjoMV5FXpmSObhQW+vuoKPKoJmaQ3EXh7s4ewVAulB3 QahbUOxaFA100fOuxdRYWn7SSd3FHpK/mf43sh/phR+j4K30Jc/00xxUdNBpb39Gu98dbH9Gh8V3 VT/C4rtvhRwgb4yuSj3agFk50WZStMqBiJ0BhSCkR/RZ2CyjB4TtAbLZYOdyhFdvJkd4jvAHifDN cUR5lVbN5x7WpP5H0zJ9VaqlcE1f62AlBx3kcHjIGfSEG+iDYnM5pAZWe7qVo8ShiUPT9rpC189a OaWH3h60uzm/pdPvtnKe0j3tyToJZxIMT1lRVQ99jYrP5oSmz6OH9umJrne/KJ4lwyvXmEsIkv+t XcQGdWVuZJRRjjtBJQrVG1kcxSf0gmAe6IV2P/6SZ7tMOLkegX34u/P30U0hIzTsBBkqOZeTFk5a cnIJTloiJFrYx789UBt63aNOTAg0L2nJ87I1r6cRScfm1BSTInZoWLCB3tHHh0+X7+QchNy4EVpr rN1+etCw73hqWlROu+HSKGQ32A2lmrJIiOI2U+YkH/PoDs2ji63h7u9Cquq25BpuyVKqEBmKI5vr ONMblxp2/usCTMKaR7ap68w5qC2MMd7qhYsBPfeZNGfXII3mzaRWGxBhEj8H6csNlkt9vr0/OWt/ UflyqXHs5n3rtCO9iOQPxuKY+h2mS3Ace8M4NigXx1pnI/00ok5XNY6l3sdep9PS35M1+D5uxwX4 Pr7hfTzb6T62K55XrhNrLB0pZ4FgmCPMrIlAKNmE1et5IbVMh/5vbW0F/s+Nr+bc/FcgL6BkaPBp MCK9/rgt9Z1sGZymOtoS05CeGTZMIM7sLcdj4XnTJXZVQ2lXEx56ppbpzYiiL8EJxcYp3bhEN0Va LWC0VqjCw+HbgXRfv7um6oql36n2TneqIz10He9UILhVxHKdnSxXX2/kTKdAPcF9VbxM+qnr7mS7 +p66kC5cwHI7DYd2u7W9r6ZPi7ELGG6nudFuHa7rEBx1x/UN2y9gpt2Q4Nj5ikpOmou5uurr7cuj ymYR6SksrVv3ZStIsWeRfKpOxtktxaqTBTKOh0whlKORHgRLglVhaXi6duV1suWwiHMqCSeEFos5 p5p5ovP0wIfjlpxy/NDRWx8uKe+KiTVmw4QDvXN51pWuW05O4lc++K9ocodSBHeGa6BvtJgJGhH3 fBGgbFioGpSLpvVsRc8NWb743u0kekzX6Qfwl65+IiL4Zkm58sikMkEKfnUOwRoGy+NXt1r9vDnU 1tlZziDqd6WDe+hrUdHxcv4owL9AiwukcnxlTCE9Lr+QuL6JQbyXczLgxVFfl+UHRFWe8JMXR51e Pzi8aH75EMlYGtbD6rdKcDQ0YwjDxSApvSS8Rw2H/rl+VimAEx7jzr0ic9HtNycXRzpuL9m4sEaN 8rpjTjhuypJIhPIrv2XvZmwsPPn/O4QyCxzgyrjSHYZnDD53w+Ll4YbW4Ly9jn2hF2cvO5UaSlJJ rt9p58yxsJcFCk/5RKSeEJ3L9aMKRh+41uKOIZnUxrxDxSDnf+Tn/HpJ+CZsUMdQCLjdlUKTSq24 D0Yewgera0aCERVL4hXHX/W2RLZarzrm+1eBtSRMpUTB2Ku3EK3xO2X2UpDunRqHMrp46XWH6gl2 Q5J66eVtfY562pu+GxIQM9WP0qLbPlBQ5oQBEcfeNs2YTEzfhLL8No9QdZeXjiNhOk550YjCyZ64 XhIS2R5Qau1a2/vUat/OtRZuBbVL1mBhqhXzGvGoWs87JBUQ8m9Re4faE7zBQTJWBTlYDDwL67mK pbLBISxguPJVKbRqu/214WIXq1o2Snfa7yCrQXCUgQnmiXgk/Se5MGVjx1uqL4dgAm5k8dop9OUx 4d/4ha63L9+hjlrhbrEj98ZpsgTGJ9rUdD2/QDBv75T8t4IxHPmq4gfg6rL/4YO0UxLwj5mgArcu JWVul6wuvlOdZBShJgCD2uXeByByw972HdLd73DvMWUDEIOGaPJDaGeHtHQ1s5B492vt9TslM943 v/TDhfFqOcZEozm6Am/1DmkmpUrrbKkx/r1TMrF887c6Pd0LdGowU4fheVCCilTsnR2yvP55O6XW IIYVxu6u0ISsVjwPml70N2fAiw72CLpFfOdOaWArI2OudcLU2Sm3DDvVseN1sIx5aBuu67xo6xrJ 09TVo6lFUjBkWq5IqooPPUhnOSVZ7uyQYKZlTau/73CHAEBDgbi5U9ZXjWu+suk+bIKU9zxkwezN 0Fj9fYd7z99pH0/6uq797//8f+W9x6uI5zfXvd7gWp7cWP0aPhhzSN+ofl3ZYZ/3KRb4hj8rrz3V 13VL5rshwpuRKlx3sQ4gYPR9W1Dy0KbLSMUUe26epeC1R8crQGm/m0H2OUJpV71kWZE8Jt+0fXjQ 4xDcqIAqFedP+UNArwVORPUdSZHbkO5dSpZYhfpH6g2rZFMp7YaVrNmSpqrjDaPm2rYr9t3e/YN6 mMwitUB92i1Zn+LcqKRNJSFqnbVPB2fVrfWH75XTku6UdipT48svIw9E6EglI3wQ0ragI4hsaC76 syIHsGSbJJka1MmcQ1VJOf0A7lQrZx7AoIb59lnGPilm7AAOp1NzbJJ8RIR0Y8ZijunHVYfjpMCd 3ql872aVMd/LpIeOKsZjMADlyrxVUrtg+eTgVuj2o4sYk1aL0Ux4RgujPdRGlbx+3ib1Q22T+r4z Wr2SDdYwCQs4St9ysOgwPjsxOdQrjyJRErrmaO3kW3jYM3JGLDB3MIG5YIpzPbgZzLdS1Cw4ntTb DSqLzdxXN5UrUH31SkJCQde9HdPlibIUqr42hssD0DV8sLJmTIfbIJxrLCC2JjTosDkL4WIjeiEl pN7eyFLc4vXUWynMiO+VhFv4+IZa0JImb9ivkBB89IRPhzi/rMNmNpy9sp34bsyXxo/udbuvf7iq LriV7hfAYyliyZIoTQPP7dA2bVInn4ixNsd/E9ufkqNRvZ2QnNjEvAK+1jNuFTmcu6E3jbrmNOaR 7zCRre7gMHMOZORD65FdDT1n6Y7lGgLfdSwLDGqkUsiqgpTKsQtYuWS520Rnmg7apqKPIcFUPWYM SV6o6/Y6oNYEGkJZ6lUMSVYRkiyvCHVaEmEI3U+g01MVtDGFInFaEjpQUNYYGhBThMKV2j1eSlMe irOYwFRPS1aaiVfLmCqx/41HvMFJdLDXPctRpWNMNWk1vbPTPvW9MdXTkjhAyDFY9xfQAJUORX74 AA0+j669NzbNi6Mr5IMmZkF+FS/kDNb6IiNzLjx6WLt35oZN35xdYndV4kfGnvqQdAyHabX4wwKS T6cli/vAVXQyhr6qzgFKh0lI8qlIAXXQin5bZlutE5kWjktW7YkAFVLEDxVBMwa9wCSx6E5rDtCd /NquX7KCDl1NBhbRcLS8v1uhvFaUdOFzV1p0tb5N/ZJJ/ZvfpiEKk6n5tKQ+E8SxJH6/gCLzXED1 VgOET+0nT4P8wERMgZxOSEtrJBtUpye6RnhV7IE2Af7rdZDp6IAi7tYvme2HVU6G9lC9z07JKubN z056CM7cy2VCE9mV+Fu4aYoOz1/QSDb9VyxBKLR8o1+yXAqOS3wLWtzVfNB7rZZ0XrHBsEomRimB G3rceK3Fu2rf6bjIZT/apMjAe79kAtxkX1Eywf1Ob77t+Bo0D3zXhOhBgaytZC7a4Ns/KJ/gqly9 b5O2F2trD3ZLMJuYJAx+wARz1WpHdoj6XKjjlGgWJVvug53Swvh2snicDykh0UNBh7MucX5QjbTw pIB/H5TM7hC1SAQyQ78snNlS3/WqD3IN78NwiWrNo9KLPOjSk3TBGKlFmxuvEJDEE8bWchJUbfRM w/ZehJtelxXv2m6UWbFBkvA7hHqFjQleExEbJ+E1ESlNGr17CgYg0HQcwOi0xLfsdKLlQ99WbGIf ZD+lHBuULMfC4iUGkgWT34fCUROdyMFu1dX6D+QLn2yl8YUvdOEp9GQPXqQGplYHRJgbgjji2I36 YCwwqU+/o6mC8CGOVY8wIh9dLCPbre9dnbCEiyT/2Ph1k8c/ukWxaxE9FBZLmRfrqtfr38jQQfeQ LxYTSpKupHEXS2lxDcpjsahq40IQ1SIRRF4G2fywmwHqYtUrHIzcAAkhGnxaqk+xYZ7IVRX0XtcC BFKsFA8cV1VtCwuOsGJ02CMLR1/Q54EKBB6Rr6yobapqBn940j7RtE31T+UCnpXEwoPSK0ctu7IG S+/apqNzlCjQC10UPUbh88IrtiG8yel4JlGVs4ZDZw1wgDiMMsKc7dQ+CmWDqsKkj6IuXdmolN7l 6t7zLeVbipsj5Y/0NtYWbx9Halxuv2tM5IuVPafB4e/Q4e8biZnv0yThiLXds/Kg5w816NlsmJf7 J+qcNkcsjliEtu0Ej3AqyKkggd5cYx1/uA+ZPwdvTHLE4ojF4MUbdPz5YvHF4ou1cbEQzF3Hmd64 LuI6LfG9OHrCFO2Db7h+UObTN5JUtcq2EYd3rrP0/HcaVD4NS2WUZxjjxp7U0hQZHVUt+ufm68LE lJv2QTy6S8N91fTeO63d0nvRE8KPn++MJ6H1vmxyJrjGiFHoGRVjVExCD+1W4Ex2IMRzgzSF78sX iy/WQS4W0px6pTrp8f2W5Cxs4R9fu8bUD0O4ErpT0iBvISyrxknhH+LxfnRVyAoNywaN5cR0At1x T8PuM5Vw18CjEsrB8FmhpVYoF7EIL1yisCoLLpdPKLGoVEjwqLkm4Jpgi/Cprp+1BkF+nKWNytwu OXHMfYctx4hrAq4JDlITHKJTzpOG3HfgvkPpvkNMB/+svDjUxqhdVdsVFqSB74U9IfUpQtnfu8L4 U452FJpRPCspRxUIE8VHOCNEhGcUqeBr4IyivmOLLO/AVPVGZuh4y1FO7aOwsfnSysVIslqstTXa EAvrxq65ILHmPOSEjBOCbIdIv5j2wekXp18b6RdfLPVSMGDAgMFBAIOGNBEB9V9ODITzZ6F9Wlq+ eXxPWyp/gp7FzxoU8Q2t8/HubrV7Ae1DMZ6F22v9GZaemIn9tdwZ4M7AFkiXOwNPqMWljxL28W8P NIexXgY2dTMmEprjj4qUFTVmMGAF3MTwHfe1iB0axmHwHc2cLywxFzYijw016dcgPoEJMzdtFOwy JnnLxcJxsXzv2THHQrEj58ucL+e0pblzzfEJIxTppDvky4o/SeFNZWGCipBpZVFT7Gubz5e2OZb7 2orYoq4xavhOM0/ECXbUPUuseLa0J+juaHPTsuRyBKyii+KSB4nAETaMKfbiWMSxiGPRS2CCQwr5 cK3UkBHAcLuM4lUzInJdo1BGmvLo+DNt7mDRpdAWM9pJPDYsy8OmHqxT1T4+fJKbUzsftTHmAZaW gVWrr54v5rRpVTEnBykOUhykOEjlwJRcMJnGxVECvYVZhi/wsIpL5Qgljoa00XtODae5mJgGCiVL UJx6RTnlPgO18zQHZZV2e/fL7acHGay6H3/JM2Pdp9t+d/4+uilkhLqmOyi6veV4ptiAUxROUThF 4RSFUxRClcvKUVCKslHzcYJCCQqK5Mugg6hRCgJ5pSlV0zw67Q85D8mAXdCT/nx7f3LW/gLA/xYN 6snEJKq05jucsmwhBTFtk2mbTNtMgw8yHE3j29DgARljX8WqOW+hvMUyAeRPNOMRAApVy5ILpaEZ DU4vugAISqBFTUDpBVFhQt0Afya0mfnERTWlz1lqFRyhOEJxhOIIdXFUhLVNRbWYTs2xKewxM3mT ClMS3A/70xSGHM0YA/T31CFlRnYZ2WVk9w2Q3UNcLJbDUS8nb2SS+ZElYuNvjVvOmVGCxuaV4nI4 XWpZ7LN5vro08oSgJOxCrya+Nrm3r3lgXbnxIE+OI3xeuDU8dGxVtS0sOBJf/WGPEOfoC/q8gaI3 bTWfzLidSbJE3oGp6tnInGpRuhMpZspk1tTWUsO9pKRra5YMPNoFf+vZwFTm0iOqMf5DfVIgjsrB OkTayTJAnHayDBCi+V0Qz3mXCO8S0VtnkNYM5CSNx2h8V63EeKw5sksRAJciFV2w5oySXVLodqlP aOSOOGdmgzWZcd4r9auHDTLyPGFPFg42Z2jgNBnoIRNVH0ocPjWTfWomo79Mfea5M1laLL1BDoQ7 ysGaaY5RrvareAMwvzkxSikmU1CKmktvvKDAZsZTspkMWai1KonQXkzMPhs2JqCRz8ikRqpCEfXJ sa1X7VFoUF8fz0CSoiimHCpGKFR0gWlPTHti2hPTnorTngJSj+JUMyJ1su1S69IpLJZkLJJxaCVT iIIJ4yKXlj9zlk8k2+EKOfFMnyiG5OjE0YlhPi6heNKVgJVdJl0jQT7FrXJ8ormRID5BAArRx3Ze tKO/XQfjr0cyGEWDJAhWx3+8/y+aGsETWdJwa9eFyycun7h84vKpePnk+ZCP5eiUWEluyBFFzV7O H4Mu5YaN4rzR03K80dbZSB+ctzrnrdY/j7JbvipJtNfvn91cBU8PG8UfHMCzeJbhjU3z4ujKWbom /lbC/PHoesfDCJpXHj2s3TtQ+6dvzi5tL/kjY0/9LTLUHEIodcULTe/yWeLJGL/KLnA+f7QeNfsw Sgy9aGKWmpmyTGcS2/aSk3McznE4xymV4/y0EbygLeRMb1wXkcB/XYiLo5o3MlfOtogdGgYTy+6l 7aCLORGP2AWk/aKhEP+dNtmAWL0wIOkMSSHh/SwLdZkuUpNzok46MFLMSPH2sM172HgPG7HT0ksA 7LkZQRaGpjlC5ZjHoCDwh+SzJTM2EbWYFkqxW1qhYUFrbEHowtdenKU1ARfH9sRfSzwAsg22DgBL 9l3D9sYOyQ0pIZ/DFIcpDlPc0FQBslK1lOJPMjp5sfF7qrHkTHhNcKupK1SOSIYJGhaQaCTBdRZY zCblVwNKqGVFK3HkUutVFQryzXvhod7y3vHoi3i8H13lXap4jsMxnGM4x3CO4RzDdyUlBdVTns8l TLhhUdxd2nbQh4sC9ypmaz95c8P15W47YKFz4xVDHQRXkJott+y2O2Ru2XHLjlt2XGYWpyUBuxNj jlBJWpKFUcLJqwY5ekvMAXkGQ4UIQghFIaOWO3M8Bk/JMY/BxylxByOzEf4QaSHRQVtECF+eBlv0 vGsxNbCJkp7OmrYqlsGatjJNUpWUOv1ua3t+rXdPe6f0FJxNyH9IYVOp1wXsuTos0ehiZSDKMVA9 rmnbJ1fHmrbyvU/RtB3sa57IaxX0btcCpc7KsUl2c3Xpyqxpe9I+6aj5ZMbtTCJFeQemqmcjk8Hy cYmWjmXaINuHYqTgsxhPwWz1KmGPNYjy6ptMfkttTbuDCC63g9QUirE2xtoOgrXxxeKLlVN2sMYr smN52VjjNSmTpmkbGdEqBwqEOydIj+gzdM8CDbXF0gVmhZaaownbW7IYDc/6+wxkvtlU7hpvcaMi vx4kxcwRg7yCq+ZjcGuSohzq4j2RyZgliZuSrRkui4RGOWlOe3KTMZQ8p84SM3KmrRwlTpU5VeZU mSmJlKysdTdK8T0+jx7apye63v2ieJYMtDXWC6lZ7B6CHH+retcMGyQR51pnL447gbjLqjSSSxCC iYMgmAclVPfjL3nnJxNVrof5hr87fx/dFDJCw06QoWq5c9LCSQsnLZy07JG05HnZmtfTiKRjc2qK SRE7NCzYQL7h48Ony3dyPkIqjIfWGmu3nx40aDlMTSvY2vkstWaQ3ZjPG6YsEqJibDpe1alGNGbT HZpNFyeenZHjLEs8655J1UcJ7FeSmlezcpOh4qM0mGI4dZ05R7XE+MUapdE8LM+A+AwgYdKfAfPL xSiGaWufb+9PztpfVNJcaiC77p6edrvkRaRARCyQqd+5i9G9JOE8IFRGRN+sfX9nuqQEZy8E1Aed nCWu7X53sL1E6OAlbH8G85F+RD7SOpC1W61ygYzki/vnbSgYQ764qoFs/wsZ3lG+kI9wYMk8q99p 57iOQRvObyvDAR4sb/Ch1erneblq7AGNX0i93IXUWyO9e175zDJugfYeFpC88pqRy2+xSjLC/+fG V3Nu/itQHgBfyjPDBgCEE73lGL1qb7q00K+G/JDwkB1YpjejUVHJSs9L6hLdgcpacgcueSg0Wb3R qWxdzVAp0ZlOga+AbKe8/4iCuHX0DscvX2eXy9drJdcZUN46uDn9MGhVdm+BP0zR9kixmUzjy4IB vX49bZZeVG9onaWfvd4uZy8MfXV0/KaPlVc07e+4PrYxA0016D9CvccpHXL243DmFZw8zJouC/z4 ufq+R3eIqxlSljYeUyuRXvcsp0RgnDxZv+l7TZ3H04mS25FqUc2kXsj3rdMrXYItGXgfBTApLYEP D/4r2mNhZX1nuAZ6qQuskMeAqeeLoG7GcqrAw5nWsxU9N6yY8b3bSfSYrtMP4I9a/QSDh9P1aAFj FSkATpqmBPGlqYh4OX8UGHGG+DyUKfCVMYVOnvxC4jkAxH3x1V8a1sPqB6SHCc9mGJfjTqKkikOl MUh5ya9mho3RcFRek4ujdqu8TENrcN5pr+qHndwG+wjYX6okcQZwsAzAxHgEFgzidMNTXBx1AgiX AiLFquBjcPijrzbxh50a63H8QRaC9cn934eLmJAPAOLLB3CCHKM4GKE4U2k7vIEyRSEAZyNrCUjC vU6npb+vLqqTjlCE+u2bKBmMkWKQmh2y1RCuYb8CRn70hE+njaAGYT7NfPXcpZskslI9zshQalBC CBg6/cqlS3/xNTsP6vsNt50EPVFV4B0v7WcCBlSWn6mZGWmhnnJ40i1Zst/VQI899LDeeCzJNr7r WBbINti1gYgY7dxIEG7kgaV8g46UItK4EdKSxBv5E0ECwYW4TJCZxfNDsXjerBDXSzb/FE9UNTKQ rEnUQlwv38jjQhx2dLA6nn3ED+Uj9i7E9Z2asTUuxP9BJIoi6VzJlofiRLMS43oVV+kFOHrbFs3P a44tM72p+bQMN6opSXQjKjApRVLgZdfrYAwX6HXNBfoJGiAIHxiipxkeVhtMIawqCfYjMNqEBq0E jYorMO6jB9oFjFWz8jIBCKbfjJodkfUUhlr0pb/4mr3lmVTQTXUneT3+QhPO9F+B44FGJEmAGFwh Zqjt+Fhg5fmuOd7A9tIRit0adBlYz1WrfYNKo2bvDEGoigtKt2TJVl+h5KCyloyDrMH5TI4ApyCP JVtEoQ1rehqHqhdMPXXtkkM+AQsnnsurMSQ2/VInlt196BFNjPRRakHtD1ryh05IrBsgt/9h8M+0 x9ZyEmQl9EzsnH8Rbvq7URKIVCFKOQEYPkRXPez2M4mHSTzbJ6jSSDxJ9k17t0ZODScA1Wt3ryhi RQ4w1i5Qn85zukyjORiNpnpRlSJcRPGRQSq6MLHx9eihvIvFSi6s5NLOmQ7ej6FeQfGV1BRSvSm5 EYsXDvLF4osFoDCKVAHLI0ZFb5fk4oSV8pqKDZZr+PvxoTrbFzFANexmwFeYOkHklkz1dkmCQNI8 UQ5QMC3ghYIBF1dJmap7xLBOEHthTvpttVtziNimhkKuxrga42qMHHqSAKneFE4alX3LPC9sJHhM bYg15SCNe80LVyhPimAO3CvXcaY3Lg2H+K8LDENuyB3Hk8rytEJIOvUak1TuxjSLmYeTSuToIwzd DsnjB4N2eETmiUVtU+mkUlfbbhm3MynCnVeFVNYo6Qy7MPfWPgpbuIal8hUyjJa2bKa2Zhti2mvs mgsfLWClGs4wTniiDpFmqVkZ1y9cv3D9cpD6hS8Wg95cvyRA79VUez2gxayEJ0AbSUbPsLXb0W/H oxWb/AWy7Y/EIodanhjPAo4X8MnPEqD8or3wyqytAs088ZVASvQzaPlsNZrOYIqsUdUOXFOcUZGa Iq3gqoePHhoLoGaba562l1aIWxGCUQ8jZAQqbMwKohN4x/rZYECLUKX6q6G5zqthYYpj6gqai5uI MZjJGJZDTBs78/lGpcq1qJrucpTiKCUraQxByMhsQZwMLkU+Juzj3x6O8NWWvc1ryL8ZnkjbGRas h4MemmWgv6bEJwMbpicCqjukW0nSYMKdm7ZhUV010YQ9OV44mEH0oB62ILlyKRQaFlhK1sPxieNT TonEVRTHp+ydJo2PTwFcpThVrqHE0VBGIlf8tTTlrhvLeaH6aGGJr5iBRz01wpDm+gEKYhLoQx2l 2JIDFAcoDlAvgQm8f115UTDiAopsAvcQTudlLWtpfIDCGL05hzznRPGrHKMoRvmOpre0T7d3D9rn m187rZbe7x0P0GyamWhBAdJrn/ToSR0NNhSehigGMSTgfWpRykGKgxQHKQ5SOdglV1GmcZG+4x56 Tcd/vD/hEJVYc6/doMIcm9AJe30XlkgziPA9CmFr45nj4QO6VTejh1vt+uZqRAJ90L9RDMnhicMT hycOTxyeaIKgbMeRhrHnaKsYvuO+Kn6VayiqoVbEvYAMgV102q/iJZxqIOp+EJekhO5i6UKeHOvS HcWQHKA4QHGA4gDFAWrXAPXkCsO3ODzRMhZM/y4gpyzcZwpPEAaFbSjmoOH07JjYWxQJMaNuwpQm 2BJEj6BvE/8c4cyfgd3nzDlEIVuCrmnUcVAm85nIx0Q+JvJN3eMP99yHymVtUg1lG67rvChOlQso ilBy6glNpqiQikSZqP9EUSl6PGSbB5wKKF2j0lKsyVUUV1FcRXEVtUcVdXU5OlZ8SoqHRjvCsmo8 FmX+VcgCSfmSehDuMyaiZG9pLEAln5qIPRHhXLL8KEj93j5pEYmPT5A/5BNknScLcdnGnJpjgzBh JnkS0sPFtVxWqrfOztqcuXDmskfmkhezN/QAXYBarmdOVL3NygqMDWfGs8r5SEncyAQNy1okSyaa cyeezMeHT5dEkcG0nDlfzrF2jwYUxFzQsBy1Lv92HYLElvPETUoOUuSSOEhdOUvXBPMZjf0gTh9y EoFxK8atOPvji7VVqand7+ZoOXVOT3N0sblnyT3Lg/QsOWJxxOKIxRGLI9aqPDrTT0NFpyxQU2+1 +qc5t4aBwDeqsTLgoBq38e5cZ+n57zTha4bFg2XJfowW/XPzdQEIzNM+iEd3abivmt57p7Vbei96 Qvjx850BtanTLwrUyqkQp0I5Tp0FpCIGbRmBQ75YfLH4Yr1BjdEQjchbGxwdW/jH164x9cMQroTu lJyw7tyuP8Tj/eiqkBUa1ik1lhPTCRjGQSO0kJFqXD9APlW4zqKQGRp2VqK64HL5hBKLSoXEsuq9 95zyniA1/eEFXBK5V2bQ9KbtOeWaQL0U3NDjhh439C7US8GdctUe3HegJs3s0vbMi6M4kQuPjj31 IdnQOiS3qyHFNjLivEKh5gTkpYfmQBEbNKxWgvzR0dT8KiZH2HT4DPUJ778080ScvNMeXceYyNnf sWPbYizHYrSlF4lRSDl0xaKc/qmendM/Tv8Okv5xlMIs2usCwjk1j1JSok7xqSkgeJ3nZIYqE4Ij CkcUbjK+QZPxEBfrqtfr3/SpeKNJxbuLo1YrRMVpLGtBO3vlCLG3bUoLvLycN3jQyZm9ZUBBdRIM KHxXQAFLi53pjeviXqTmLKZNO3LMycVRu31Kf6mx9GeOe3H04P/n3wus7hBawA2k70HVF1kPdbCO 9Rb+Hend8177vNX65xHdKnnFwgUz7geHhkTx+7yxmYRS1jtLR3JVCGng3jsQDv4OxoJlhomWHOxC L2kirJV5pHPZxzz4TXKKOuaboocUNZTwwWuBgqXVCh2bNHDgxSplW1hwBN3IYY8SyegL+hynJXhE vrLIEHm2qaoZ/OFJ56St5pOFs+naGiVDPicXHsxk3tTWUsO9yDi1NUvGAXKFJZ4N2wdAiL2JpGdL agWMEfLMp0qJ4AmaN5qgOURFx6QmtZJiUhOTmqjKilJlpWaobF6cEcG11YLjPFXfYGEKKymykuLX eZqSYiS+6QVrtJV+BocpNcRwj5h7xNwj5j0FF0dFhi8JOJ0b7p/CV5xqYVir1gkMAQ5SBjrPNplY Vj3MMxw7LmBf4akiximHRBqiYYS3xcyxISaAtUsWRsqwWClQDp+ZCw9SDFhpMXdcWsbEK9S3qsdw 3sJ5C+ctpfIWvdfavc1Sk9D0ybSshLw+Rya5CTAvbak593Eh1HVRKaeizszHDFTuVRiuXGJCcNvt /6MExYAq+JPpAWWhRSeuMRHa3PhTIKXRun3lEDHYwmBLDruOxY8A7stEpkj9TRcqZAQ1pCeg+JMM l1xjlY2xs7R9SMvnltINDE0vjmvROmKxWgg5w+YKw/IcTe61ALowDrZxYbHFzejhFhFKOU4cnjg8 cXh6A3Z/c1rWn0cP+gCE994XuTUH+9EN34FE6MZOWoKGbz89aPOl5YP9PDENbAi0BGGB6k56dkns ktglsUuioYj1xEQpmE9JcZqYMc/nSztco1nEFg3rP3nCJZkFiel4y8XCksvdSNY6/I4XaixIVQbF gBycODhxcOLgxMGJuLeWgeZ9CeyOuDMrTRvFr2YE6YYFJmMM8Z+QsqlRZHJcnzamyxke7cVZWhPo 79oeNpJiG6n1CqTHcl4UQ3KA4gDFAYoDFAeoXQMU2rm2BxUgENMUz8ohShwNtakrhHZ7hz6C1D4X rkGidOg2+C9C2I0n1+w1sFwPglEGi2JsmchZZM3NZTWPJPNIMkVoFtctWz9meJfGi+v+7iAor6b+ Nrn1v2ghd239jLC8JPq9LC/LqLRwkclFJheZXGTuUWS+FxAsFN47rhh431hGTA8rBndp2xSlUGXK wiEe5eZh724VxZSKncMUhykOUxym9ghTij/JQABrzL2eGyo3L8MCDWvTuYIU9vyZCBtzUjIevThX GJNXzYyCEkaDELPwNDw5XOyhFlkcnzg+cXx6g/h0iIvF0urq5WQhPhbiA+WnjLT6gBKvfbTDK6vv V0ha/Wxf88C6LK0uddYpTW+gtHpHzSczbmcyO2+aMrb2cQmw0TJJdWiliQ2ON/YRyob0KmWXZAal 5jtEKsGavpxKtLs5mT4vKl8vL4oCm0KIiR68FlMDM4RJH8brjzhH5xy9SWLZalRfRXHqBmEMORzi Csnzpj/TFkt34RB052jC9pauuo2YQ70apllfkPUFWV+QB4+L6yKvSeGPpmX63DvyFsYYywMXLnpA rlQYfKE49GmtgTGKNDDWs8fOs3A9qZUxNohZz/UochrfeEQBkEzvOEhxkOIgxUGqeJCaQk9uovjU wripgkdUtjmRQbeDdqknxnKaq09Dx9B1ap+e6Hr3C8TlLicTk75lWKCWA0KdB2Nf0WyyYk6uo7iO ygE7WfI0SmZY8jSZIzd+mGeFZCX7URyraAoZsSrYGSILJPT0ENLpwc83v3ZaLb3fOx580YJZ06Vl QTNjIsYco7iMgtcFAHxxpPMOXFf7VbwB9a45uqeKP8lwyzWmhmN4a+yaCyoKilgiSUKpdTFF7acr zXOWLnQGKfzI6CRbUV9U0g5XS1wtcbX0BpHoEBeLSeDq5WSCSbIDoVecubVFY5muULBrxbQ95M7m 5OKo3Wnty1v+oZDTLS+f5Cq7SnIDg8AS9PeDTroyiL6vQfCbakLk3mpN2EyytXtk0+gL+rwG1O2t L9wfnnQBon++IhxC+/pF+0k5VSnFQ+Z+3CTt8f7HTaRzjOI/5vZhMtbj1skKPytngVwu+ZdFSZ9w z7TYTI4AZy2NzFoOcZW4AOACoO6jG1uiNF2hZAHQ3jffrVsB0NnXICWD/bUA6avVCp1TdawZ5fzN LAD0dQnw31+0j8KGeLIFZZB0HP0Q0YsHDzl6cfSi+oprqqlPQUp2v5kzzZzp5nCmt6S3AHgzyLD5 FLRNhC5PGMWNcrwfF66TZ6IIIZGA8dLgXaqBQloAe2g1UWEPzR76IB76EBeLMTD1cjKcXD84uXDo owsVIGKp8SxG+Iu3zLv7AkQ/FMZT2FhFG+i9fc0T5VZ5fcHweT8wflbCtnVG00qYQTbX2yqpEpfU dZzpjUtZt/+6wAz2k2vMkyTUvANT2XuXVdcozeYUM22WNauypbaWGu61s622Zsk4QC70Cp4NLHIj Ceyxgf+QoF7IbPnvL8rxOkTyyRA2J591h7ALB7so+eSLpV4KhksYLpGXqN0KRinKLqaPLhZPr0Xp 8mYemJpPx6rdVZ7I8Hay4GB/zf6aZ7x4xusXghOylMza/e5g+yHpnPLeaN4bTVjpN9gbnRfw4/D2 Kf1NvOhjSOhHynxYf1/zhLD1fR7YFD6P4e1gnK4mqShmx3jRB0VG3C436L1l0nY2Fn2scMnMZR+a FGRVYEtGxalvVx4V5yqHq5ztCazOun8I0Qz3bq2DuMq5UP0Ii5UJFiuzj397oDKC2czmoU8DZTvM Zs7Q12dUatMZt/qnOVkOi0u+kb8+RIXBbGb1QDObWebjKq5ccUmv0hWGhC2RXQQCX7vtbe6ct1r/ PJKEycqyJodyMt0PoKYsOHe3vc0x84QwbTPh3FPC2iLqsoT0pJ3xiDw1RW1T3SMGFYAHMV662I+l XTm2h83ErtR59xQU8hCxjsmTHOuYPBl2DehCUffgEBeLk0i+WHyxNi6WkkR2d1OJjWVJ1Y3wMsXZ nkR2d9OMjZmnaKIUPq9enIA+J5Ha7eWvl5xA4nhLTRvuGnHXCPtscBzenBt3iASSKzNOIDmBTCSQ bpTV1IO6lzFDmy8uRcPqNR6u+dWxxYmCdqVw7mID++xxVW/J844873iQeUe+WHyxcsgMTNlETlK6 ocoXiy8WX6wfdOKTi2/1cjIFiClAB2mL8sXii8Wo1gaqxamgeikYvGDwgsGLjW4dj1moTkJv8ZjF y/nsEvTQi6MrB2zRcOqJG5witslGH3Ta28tsvlh8scy58LRfxYt278wNmzgC3+liZXS5atzpu3Od pee/04SvGVaZlh+S6Ib0grXgn5uvC9PFOf0gHt2l4b5qeu+d1m7pvfD70YfPd8aT0PqstEz80Cwt Na4xuMbgGoNrjK1CI1xjfNdUqGbxfXhr+8K1hX+8QWxavU5S73vfP725uQqmZAMpM/eDY/sech3D G5vJYm+t9zH67mmsjLehDltiWDN8ZQ1K2jbe54Rg5qaE9uog1IPcuINCXFOSemM5MR1t7EzE2JP7 UZp+VEzyjc6ikBmSS5rqcV8yycBBZXe5fEKlTBVfVzETt49UAItLOy7tuLTj0o5LO6refqTygCIV CywkqWQcsThiHSRiqQILbbr/pZcuxBQEqiuwIMf/cwQWOvuaJ0IyGrl0YUA1SMNVui7Hf9rOiyUm T2IugNFxWcYdNzgFKTfBmtyHVmE+ZPbIPHQVM+EBj2RWrjdP47VeDQjL8Px7YUM9U0yIE/PeFcaf ASqQCbWOZsb/sXd1zWkjS/SvTPFykypgJcDYeMtUbIwT766zFLDZh9Q+DGKwVRESOxJ2nF9/e8Tn yCApCUoW6eTFNsY2TKY/zunu0+4nnwUeu7NpRyzr8UA4IUP/YPtMikdbPOldSqBfdVcCMAswexAw ewjDggynbpyI84jzhNG2VnM2Gt9LgxwvSxRyGAks0cn3Hk+hWaIWWCLWFxPKQF1LgB9CR7byJuCH tufVQkDmf+moDsf/TN4Ifgh5I3QKIjoFuWvObLeqplazKd74He2aee/JKa2XeRRpjqJgvZcSudtF CcrpkWY61PZQ24OwgJ4htsymES+0gGk6Bf5+mrCAXBFROR+W+Ni/6dRMs/VPsoh63uevriQfu0Im 5XXhMeQ1sWuX2aBaZqXfxTN78uR4MW419wWzXUZXJaz13rpj26JKr3ZSh6g/gUfQowTqT6g/Uf2p KLFoJclCH/vi3znJt6g+UfaHeBSOXyqzq06PmY2y8kNMxawyu+PSemBmq3WKLhNUC1AtwK6uzR2A lJ2zLe0HxCmVZp26Hz9gyG/zJyayctNXUJ8SZLka51tKlfz3MWbM+yD1kt19oa1qjXjyW3eyYsqZ BhR2VA2OEFnGH0x7DxO+770v4SQwlI5/0ByL5thdTQ4xxqdMaOVlVUY8W/nYlGOH/Wsx4XMnePn0 3tZD4W9eOHGSTPTjUm+KuwlELxIVJCo/TawshSkdBQER8z72JirEM3zsvq8bhnl6UjmDAmycG0Mo Rij+xlCcZ/+xRVl2h4NbqpyoD6z7npFbYaFfKbPHWvWkap6z0rV9bwfcKSAe6ro0KWiJcSokCDRE SevLygdcMFzwLhccPibcyl8DndwqHvO05Y3p04ivkSskmI+OjnaHyvOO8H02FI6wvOl07qqqvO25 Pnt13e0MX//KOvSw5xIXR3KhE24J9qpz+/pX7WDAOYFzSiAosLJ6FY9z52VTx444EL3ldjXXsoPt vpd8muf1PFwG7OycDWZCUGMCd8dsrV1tu/fhA4Hkrj+1fZ88dalKbQ01w2jp7Qt7Dg558coONcIQ eTHy4oPkxUiFkAohFXpaHEHMjHEM174qvx0F53eQ5CeS8RwByoz576Msr/3xbfW0VqN5AOrhGP5F jGbkHeZhL0vCEfRDPC3ccQinU73/ZW52FPc+/t3vbupRd6EyZOHdYK9oq0btNRHap+zTuy+LFFdf 04RQilCKUJocSlOHoKMKrN/kYLZYhBfc7YuYk3MegVZdEV2QFHjUIRxT3El92feTTU928ECTaM1G lN1/cUOOsKf0a86n/WlkB0kXJN+jir/4S/rMrOn0GZIPJB9IPjJIPmBYMCwYVgaGdRS0wdekJ3tI BGq4vdWJgh2lrrxnbtdVWwSTYuduhb8EMrCexKjglyCsjaPvHn33qnEROr+Z6vwWJ8XYIhI/cMd2 y+y3ath506ky0niir/NY0vqa7Kz9txj1h51CR589GerlfGx71Dc7FlZ4Z3rSIyl6P8rGAgkDCQMJ AwknTFzsL2RsBSlN7UrpXI0lnwQVBRIrC5hQCRPlinHCXpEo3yfS4tNcN5wRnBGcEZzRYZyR5lp2 0HM5L71TIfleUsaX5hjyWnxvvy6zGzGScy6faTzBbKC+Co4GHA3UFTd3AKJF2gwS1BXlD1RXTM11 KWR0NFqLqd9VHKpEfbWN+mrQRn0V9dV2xXsU8tEWTyixIn3fpG5Gq1UDXQS66DB00aXzKHylaTAu s3dqdcyfS6dzTkscSOtsaE8Foypa4FmeE66T0ZgVcNfgruGM4IwO44yupPfkC1kZcV+M2eVs5qwk sXaW1Vb5UcU04JRILJu0rKGwclHCwtKsFpYWsgntleZbildRUy0LaY4gr9W0PZ1mNMa6qjVSue23 uStQams2G/HJILS+oPUV8uS15fpkh5Os3lIt+WvUGYE7gTvjXQ0tmDTOEp5SO6slOCyzftpI2vTd aJ6EO2LoTq62yYSbwihbuvHcwKf7/dP2g6QuSqHUtiOzwyjjTFyU8i1DgVIbSm3tCq1Ir1jEOvkV YsIrcrO+2EfxDcU3FN8y750rJLX0znOmIyHvy6xDpbckkiXv2cg7/omk1X1Pn47Zl5bllW5ql9mA LoPSnn9bZV1pf1JHQoVZGvoMS7J6wgIgDCCcgHIBhL+FYSpkQAq7PdTWofUyIvbXKjMOXVJ/KzNe 12S1wAWHBIcEh4SOkMN0hGiuZUcqmPNpxu0h8v0URcVspDmnvGbMewq0mLUv1VGQ1YMxWoPQGpSm zBw3orUl/ZHG6+Z4Xd6q/yXNMeQ1+GDWfhKs6XHEmwvEmyd1HTKvF4Bm0G8aOuvQWXeQzrri8J4f b/vVejPclPd2cHdJJZbLMZ8F9qMofCnubu4EtuSBSErtct0btIdY+NseC3ZFBbpw+bNZh7oSOkTW KTAYhqwYBmR8yPhQWEJh6TsKS0nZTM6rSSrhbS1WQy8T3tu7gRJ3mNiOYBNPsg+ebYmw0D+4G+xM b/bU4Jb0Hnw0fDR8dAY+GoYFw4JhZWBYBaK7+jed5qmpCK8Py706d+g6b3/wErXCC0hyldnvyyb0 YbXwbOhQSGnTnIZ8TgIQub4pbWLIr8XEdu3A9lzmTVjwoBPEyFKQpSBLQZbyHRTNVnfVn7O5z7YW uhEfQSkMUzkMzUiJWSDU8JxS3amhBIMSDEowaLrZ3AEsuMCCC6juTLmrTOLh0vXti9L2guIse/Ti uqc/DgfmmWkYJ9DVQMjeuGuI2i8W8PyiLoX/paNEw9DON5GVm74ClEQsLCXVgj1NWVu4gbHucHBL ZMVQOMLaHmb2w9LmrRsI6YqAWZ5LYvf3JDU9UIs2aFG0xu+AzQCbATYDbIaKUoL7waVv84vSt/ok zbXs6aLI8awYtcumOYG8jontiVraYhV2OX7krkXh6L0IlOq2Tdq4r4a3g97l+9e/rmKUdooIUQhR CFEIUQhR3wmXiLJoI0Q55/6MWyT5O6MV6gSJRKnNOnzGR7ZjB8+kPvfv3JZiKpSo9Yd6tV412aua YbQqZu112C1qtFCJAa0DWgeVmM0dQCUGlZjjqcQAUQFRAVFlgKhgWDAsGFYGhlU8LplY07kflBmV 8LijA849h1EwWnldDO1+nhFg99mNGMk5l8/MPCmrhsmT9TMWn3zs8XvBztCTAfC+AW7oycioJwOp EFIhpEKZpEKSavXSt8f9nrwoGYZRJ128bkl59eNbybi3jXLVwFS5lnwSLEO5VhfekQblfXsQrcfp DzupTqFg2SCfj22Pmt3GwvJDlY9Uh5TjXhRbNQB6s1THULC7ssIFl/N7gljhRnPtmJC6IHVB6pJB 6gLDgmHBsGBY4QAIrZFfzX9otePaaSNhpT0U+KHAL36MAn+BlJOGg1qzapoN8OPgx8GPZ97cVhzP soLb9LH+ttejmcXbHgvF96dibHM2mI/8Z5+ETtgrkmqlIZDN9wDLidTdlyhhGwq2oWB8GqOK5w6n GbrlbEjKxX/tgMbGZw+em6j2p+TC88oPtynWhCHogcZiHDWJSB9ZyJxzS+n/LdTBTb39BiwWWCyw WGCxwGKtYWLLbBoJJmEYp82kp7RatYSnmC0jgRw0a2e1RsJvqZ82kl5uo3kSvlxy9pR/+8fZXKEi VU+Grz1fLSPty3nw4En/fyQnMKbeTx+qNrHeCFARUPEgUBG5L3LfhOCKEP01WDy3IXqPGBBjg4CI B+4KtZOL2q9A8YLiJYOZef5FCXtFs9orWpxq05+S2FBs7EANe01OwKvAq6Qsi+xNWmplxh+FO6es xaYdSaLw66LuuPxiu1rytm8eZ1k9AnQEdAR0zKBsUpzcLpW72ZrpmknPm3SlJHwRPM9I8i/nu6// 4K5LVetUx5TXmv6+EF6r1Y3TpJPZanZAuEK4QrhCuFIwMlYY3yHV/L5wx0KKsVKYuZKCf1pU4/b5 InZDJIUFkgIkBUiKzBvtEcgRyBHIEcgTA/n+rVvdKbedc0YzKmHlskq4kiqXb7yw1FCl7VsaroDD gcOBw8nA4cCwYFgwLBhWbKsr5CN0J0FriNF4/6OXQ6tIlcvG+72MVpekF112pTbNSmTDaOlDSx/1 M27vog+DFpZef8uC2Y7tWx6cCpwKnErWTgUQW8+eMTiHwbmDDM4Vp0lrSZYLAgQjggNvLBW9QZIn zKTD0cDRHMTRIIIjgoMkB0kOknzdWwV1msWOL62TcWhPaWfee/HE+t6Uu+qwHi5d39ZZK3o08wat 4qTGRI+7D1yOCz89diPsQHzVnALSGqQ1SGsySGuK432vxTzwrQfBhqR9+glNe7EZIvgI8BHgIyJ7 VtBbpCch6C0CbKKq9CG6GvbugaWtEcuKwgo9VRfo4Y2SMKcwXh1jkA6DdGuyB2o/Wan9AILr0Q8p MlJkpMhIkWNxNFJkpMg/IEW+8gpfU7iaS6pjaW3CUKSbBOvEGFtzI6EKSCErpFCcmkJX2pbvRyTX AJQAlFCrzKBWCcOCYcGwMjCsAgXshZTPyKuOQrzwRiwjOCYUMKEgtuAS0EFW6ABRHFEcUTyDKA7D gmHBsDIwrOKkx79z55m7Nrvy7m1XuLZGp8O/wL/Av8C/qJJSrCT+fiXdDwS3v3gu+9uW1L3n+/Av UPWh24Ttn5lKhSFwI3AjcCNwf0fgXvbgL/FBdYUP3iwD+iqeg0UHiw4W/UeoJiCmI6YjpmcQ02FY MCwYVgaGVRwW/c7mHvtDgD3HXOq6/R79JFn1kxTHr7yb8yd4ldh5OwzlYigXQ7mRSSfo1uiQBkO5 Ki05jNxnTCFYIelibcHSytlHkZfE/PeRJE97Sfs7wq5OCdS8eQgzELD8YPnB8n8Dyx9jbStnCfpR j9VI6JHQ70roYUqRJB/6DpEDAeOWknGDKUVuDkwpciAwJZjS03kYhp3txB/Ekp6sglj6ocQSsJJ+ /YCVgJWAlUqISrpbQFRCVCKy8mX6Zp7Va/GtbjAlmFJWiwJBO0RQNmiHyIGAdkhJO4SuXbiVvwYq 0qUwrBzUptnnqXPuz7glLkozKXwhH0Wp3ZPe3A/KTASMO1VaHrP8d3yV+dT/p2Gd/vOMJup9diNG cs7lMzNPyqxmmCer97/8+LHH7wVr/aMdB2C0HuQBowGjd8Ho1BaJWv5oJ96AYcGwDmJYR5G+pHYX e3ff3boBbQwXQeVa8kmwO5OZSc+bdKUkgwueZ5QL+TPhOIOAy2AB7dV3pG+P+z15UTIMo05W2C2p yRy5bM688dzAp2dx37Jf7n/fZJM/f2W8SnX+FqP+sKMlMAl7PgpyWxifj22PWd5YWD6beLLwK2Fs ZT/eDHflBUxaw4LL+T3hJQUVGtoxARMAE8RTw6bZMs4SnlI7qyV0Spv104aR8FsazZOmegrdyYCP /OMMXcAEwAT+RQmUZlaUJiIWIlZCIEHEWtEyuasVfD/YppS469IyGGzSvOPSsyxPwwMJEBvOF84X zheiSSUKMBvCcCIrN/0lcluSjfulwYckCG55U3YbcMfmmvOBd4F3gXfJwLvAsGBYMKwMDKsoJSfC TIuFmiKETtXpAjq8CRbB3A5jedUOEM6x54NSQ+z5wJ6PxR3A5IE2SNsym0lVMMM4DatgYRFsxeNp vwS1BdQWMNKjZ/QwLMneiyedl/n5jVwKeKruMwBQ/bqiQxYdsgfpkIVhwbDA7GTA7MCwYFgwLBhW 7BYCyCboTgIKJAqAHUZwPXWnEzAWOo7RcTyXNlhBsIJ6PAIrCFZwuZsuHCeisaKdFRW6Jwm5PupY WgkKhgXDgmFFZKxO67WEQUkak0yYk4RhwbBgWDAsjEtvNEwoZXspbLJ68FpM+NwJtiRPlt/pbT2k LGq5om41WY5UkDgDRKxdarnQIVAyQjAspUKxEy42G2aCnjIMC4YVleJCxGq0EmgWGFZY9dGoFijn bCVyKxvSNO5WDyJiIWLRXVgMHkCSSjXdhtPYKBDvTuPQhIsmXDThRrg2tDTpJWS0NJUopqKlKQG5 oPNCNxvUsVDHQh0rElvBCoIVBCsYMYoTsIIvYBjIC5AXCY1CIC9eWA1kfwmpYWwkdmILuzcj4Rdi MhgbAXkB8uIItoKhjoU6FgYdMeio7gDmsbQmIdDtoNtBt0egDeh20O2g2yNGAbqdvyAOQbeDbgfd LiaBavWBdju026HdviNzAsYCxgLGiqSTwFg7PIWJCWJMEMeWoTHoiEFHLEWIxBK0NL1gJtDShJam RoKoGFqaIn4ELU1oaUKBGC1NaGky6pRTdUuQP9vdOAXyAuQFCsSR7AkFYhSIBfeDS9/mF6WJrNz0 lTY6xGTiFeJBXoC8gJhMJJZATEZHYRCTgZjMRYkaCeJjCcgL3WzQeYHOC3ReRGIryAuQFyAvIkYB 8gLkBciLiFGgQBw5EBSIUSAGxgLGQoEYBeLYNl1gLGAsYKxI9gSMBYwFjBUxCmCsyIEAYwFjAWMB Y/08jJUiRtGCLJoveblcWBWbwtVZ9OHGcwOfnsV9y7YvStviAPTo5o8M7anw2XvxxPrelLuHK3Rv /sSLZqyn84B9njrn/oxb4qI0k8IX8lGU2j3pzf2gzETAuFNl63/dzzObnsRUO1ewaOoKm4Ol5026 Uh1G8Dyj3+TPhOMMAi6DRaX66I+pfSNGcs7lc6p33nXHOXnfu68HM0/KrGaYJ+uLEX7yscfvBTON f7RDUrKb4SVZmYrax9g5O7m6aqlLvmU99XrD6J6tH9zax6g/PVzNfd08ady0FsfsCyvore9Yyt8/ oB9STz3rNM1GZ9Hkfj/4Qi/piQQCaXKuqV7JA33ePKsvZ6hm93dc/Z3Am6nn1Bvhi7XvH+g3rb4c eUHgTTdfK6G9zVcPgo+FpNXZRvjuJ54XbH15Pw/CL43F+7I8R7mOpXmeGstXMfast9Ie03cc2xU9 O7DoVdab4Q/RaS9OI7TOkTd+Dj+hH5lPhRu0/y8AAAAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYG AABQGwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1N G8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS +eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VE YoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/Q UJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmv Z4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slp lkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn 8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEE qWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPj Bz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27 RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXg HQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUz D0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+ dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZ teaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh3 8ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxHal1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Y k6oyYftE+V2EO1l0u1wE9O2vuVt4kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8 sEMeU8YGasrIDWmaZAn7RNCHQb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChR yiUc7MxwJW2NhyZd2WNhUx8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdC nZlb3YhmSp3DrVAZfDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7 qG6clMeKuQmA2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/V XG56yMdp2xvDmRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0 zFQWAizRnKz8y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETs Y3C/DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6Vshvl zq+KSfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/ BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QOCRvqGriq93YP RRDqpppkZcDgTsaf+55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9ErNhV7XqzPN97y4ro iVmb1cizApiVtoJWlvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UV wYcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWL NHZmYcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn914qN74OgtuN+fMCVNMME3JYGh9RyYPIDktxzN0o2/ AAAA//8DAFBLAwQUAAYACAAAACEAcJ1PcQcGAADWEQAAEQAAAHdvcmQvc2V0dGluZ3MueG1stFhL j9s2EL4X6H8wfO7GoiTq1TiF9Wo2yCZBnFx6oyXaFlYSBYq24/z6Dilpvd6dDYIGPVma9+PjiOPX f31r6tmRy74S7XJOXlnzGW8LUVbtbjn/+iW/CeazXrG2ZLVo+XJ+5v38rze///b6FPVcKRDrZ2Ci 7aOmWM73SnXRYtEXe96w/pXoeAvMrZANU/Aqd4uGyftDd1OIpmOq2lR1pc4L27K8+WhGLOcH2Uaj iZumKqToxVZplUhst1XBx59JQ/6M30EzFcWh4a0yHheS1xCDaPt91fWTtea/WoMU95OR44+SODb1 JHci1o8kx3RPQpYPGj8TnlbopCh430ODmnpIt2FV+2CGuM8MPZT6FZR6MfheaFOgTizzdIm8r5/p I90euvi+2kgmhzYDAHQUTRHd7loh2aYGUJ2IO38DiPouRDM7RR2XBTQJ4Ghb84Vm8GbDy/W5V7zJ Rat6Q4QMxXatmOKg03e8rg1oi5oz8HCKdpI1ALflfKAYnV6da/6JtTw3mMyrWnEJskcG+TiWRbQi q+u1lushAv1eHHolmokEJ+QUAXAgwiuSMd3ftl97yMgI7TnT5+hKqj1AKvIpVek6XMmVleSFGqLU p+xj+/nQQkDG8HPmJyYZ5NvtXxb5MHl+0cgXHcVkQBdNXvyPpVCic95ep2VKdKz66mkKTNe2hUKZ xD6wZrBt+qAkK+4/c60G58+QSr5lh1pBEGvwMvXEt4IBAvtzt+dgDeT/gUk08V2bDvxiDyUowOO6 YwUULAGcSFFPcqX4IFQCU0fCoRg1zAzS8Bqm0XqYZ6DRQqwAm8cz6k6UXDf+IKtnwH/x4GgFgyzA t8kRdyRg/sqq5Kb+plga5OvqO1+15TsAXwVTz2T+CxH8KACoKzTvI0zrL+eO55ypA5Tpf3JmOpHX VXdXSSnkbVvCSfpVZ4upibqd8DEr++nhsxBqaoNlWY5Lg2yohRZ7zLECf8TaU86LOtQJPIJaC20v CDEOCekqRiMgK5+GqDXbon4yQug6Ntv1gxzVcWwntNEIHMe1MjRTKI7tjOfp2o9DiZMmWD5OQIln o5zYymOckxMve4Hjps449K8jcAlN4ZZgjtETjufkAa4TuO40P651dJ5hjlmjjmORGOV4xLdwHd8P M7Q6NCYkcFBruZ1aqB/PsmMb51CSeqg1z/NDgnbbC0me4dYyK1uh+fg6AtSP7zjUQxHiBwA4FFUB cVYhit7A890Q7WkQeysfrWiQeMTFOZn3Ag5Ci65cNJ+Q+lmInsbQs0Pfxjq3IhQAh3Ic18tRays4 2zkaQWx5CUHRG/uu66JnO/a9DMdbHNpWjFvLKFmhUSeWnRE0toRCeXws0ySgcYziLVn5eY4iJEm8 FM80SXxir1A/qeuGaLeTnKQvRAAny08xa6ntBAFa0dT2SY76SV3Pc1H0ppQGKVrR1KNujlYnDSjN 0OqkCXEztAYpTEuKWsssGIo4B2DloJ3LMpo4KK5zQvUFGJmwuUOsHI0td2EeoNXJYcSu0AjywLOo 0YGvth7L8K1uIr0+fZLTk74AzZrh8pSwZiMrNrvTCxZE10QbeR9X7cTfcFgw+WPO+rCZmDc3A6Nv 4Fafww1xYphD0kRl1Xcp3xqz9R2Tu4vdUUKiVLitvnuwpbcVLv+W4tAN3k5wFR8uNpM7Al+igVe1 6n3VTPT+sFlPWi0sSY9Yh7b8eJRaaXEpzylSsFvD+gJWWLub7i+8vfm61qJwD6rlWu/f/I51HVyE QWSzI8t5Xe32ylzWFbyVsIebl83OHnm2vvApeNM888IKnRlIjw9aYHgEqfHhQnMmmnOhwZY5yLkX Gp1o9ELzJhr8D3CK4K7PJWxz93DVnh41fSvqWpx4+XYiLufPSEMRzCXzti3qQ8kBDaUoYDPTu+Kw a/R71nFou144AH0iMoRxA+lnx4h/g/WTl5WCfz+6qmzYN1iALNt8q0bpmp3FQV3JaktauLuizkqm mN6fdCevlOEdNtfrWE5RyYsK0Lo+N5vL/vLHkFdd9WrNO1h1lJBQEbNd/GksX/6QefMvAAAA//8D AFBLAwQUAAYACAAAACEAH2WZkS0KAADTPQAADwAAAHdvcmQvc3R5bGVzLnhtbNRb23LbOBJ9n6r9 B5beHYuiLpZrlCnHccaucjyeSKl9pkjIQpkXDS92nD+a75gfmwYIQiCbgAhrXZu82BKFPgAO+jQu bPz627c4cp5IltM0WQzcd8OBQ5IgDWnysBh8XX06ORs4eeEnoR+lCVkMXkg++O39f3759fk8L14i kjsAkOTncbAYbItid356mgdbEvv5u3RHEvhxk2axX8DX7OE09rPHcncSpPHOL+iaRrR4OR0Nh9OB gMn6oKSbDQ3IxzQoY5IU3P40IxEgpkm+pbu8Rnvug/acZuEuSwOS59DpOKrwYp8mEsYdI6CYBlma p5viHXTmtGrRKYMCc3fIP8XRwImD85uHJM38dQTkPbvjwXtgLkyDj2Tjl1GRs6/ZfSa+im/836c0 KXLn+dzPA0oXgxWNgew78ux8SWMf2vZ8Tvy8uMipvwK+AT2mUNH1RZJT9uOWfeg0C3L8+JRVGfnJ A1g++dFiQJKTr0u1EuXRmoaA7Gcny4sBGJ7yHtT/lZ7sZL+qUq1uw4DB8C0rLwJSyOY2DR5JuCzg h8UAPJE//Hpzn9E0A0/ZP1uSmF7TMCTgs7JcsqUh+e+WJF9zEu6f//mJO6B4EKRlUiwGo+mMj0SU h1ffArJjrgPVJT4j8o4ZwOA9n/9V27qso8BQV/Et8ZlcHNfaYmRt4VlbjK0tJtYWIF9LrmbWFhCH LOuY97YIfO4ArHyueBYf0LLlVv1HeUWLiPRuw7JcF3YGRZYmD73xr+Ld1s8pxMaeNF6vPt869xmp 4ndBQmZZ0r0Y53ODKO4jPyDbNApJ5qzIt4IZY277ot2lznLnB6CydiP6D8ctfdgWznLLxdqGmQ4N faksb2nOe6FSMDXFhcrs94wi5qYjQ22fSUjLuG5oFVUadXr9jXmAaRiPDxuzjnZUO+lpieucHrZk LHXUOetpies862nJA2qDIZNXf4T1i9PlCDOT/1ymUZptyqge07bzzUxeJI07qzU5krTscsGZyYsa UnEuggDm6Y7RMfV5rxm9vanbe/Ho7U2db6tIj2IiooUy0qP01pUewiSwL+SJsiX6cWGUK/vez/yH zN9t227ojdmTXkueP8u04FObqpxR/wn3JoGlX06cThyPr+h6tUOMD++XYXB6ByD94PSORHqI3iFJ D9ErNmnNrYKUHsUkWxlz+JDoIsfMpFwJwecELYRJtp3xC88RdvEL25uIwPEL25tYaEUetx4OjGIi ooUiJYJRrOMXhjDFr06hYghroWIIa6FiCGuhYggroSLzVwkVo5j8U6pMFSqGMLmohFCFiiFM/tkp VLwksxMqtjcRgYWK7U0stCQmhYpRTES0UKRQMYq1UDGEtVAxhLVQMYS1UDGEtVAxhJVQkfmrhIpR TP4pVaYKFUOYXFRCqELFECb/7BQqXy+qK8Ceu+h6LsP2JiKwULG9iYWWxKRQMYqJiBaKFCpGsRYq hrAWKoawFiqGsBYqhrAWKoawEioyf5VQMYrJP6XKVKFiCJOLSghVqBjC5J+dQuUnukcIFdubiMBC xfYmFloSk0LFKCYiWihSqBjFWqgYwlqoGMJaqBjCWqgYwlqoGMJKqMj8VULFKCb/lCpThYohTC4q IVShYgiTf3YKlb9IOUKo2N5EBBYqtjex0JKYFCpGMRHRQpFCxSjWQsUQ1kLFENZCxRDWQsUQ1kLF EFZCReavEipGMfmnVJkqVAxhclEJoQoVQ5j8k72Yi4ijvj9TFeran3rqoEb9X2aJRn0hG5JBvgZB Z7n9oeqzWD0W39P3Oo/9kKaPjnzvqdLk8f1GPxC6jmjKj6hfDp53e/xNMn5Jq39dv/rj0rmuXtkf RueDi9HROTnkQKjpDCxXgKfHQMHiZQc5BTv11B1SHVjyB+Tb8BawDIgbyFgQeQfMmCUigC1PxRCP eY8Egfwz5OyEdZnh0PPGwysRFSChhIFkrRSSaxI9kYIGvjOZ7LNIRKJIx4+8lvz7JctC4S0Z1RFY SRTZZCefvrBu1Nkoi8H37cnlHXv/pmSGcDYO0MLLMCLAgzLi8gQNlYh9ogVv2dqHPI8/WNoGoimB N85dz/vRB3krrKWPhOzuAKiioXr9DKBr9kYcRnQ05u8p/E1BIGup3vqmZRHRhNw+RXX9/PAKmBCo 7bFh2TgXGYV8k6pT1d/LnP9/JJnsnyfiXP69Rt4/2Q9R9ewo4kda4kULfhLi+dTySuIpp5+KYdhT PhIKa6iCPzuKck9LuZiZfhLKuYPoKRepbPtQM5041fKPBRAUiBq/GnWiDJBYnjUGiD87aoCqvL2u YCRC4k8yQNyd3mCAOmKXMiZvI5qJVjRilf/WY5K/ek7gToOGYd2I/doQ9DYePtWyKer7cdnkw32A TcUb5Ty6nzVHdeDiszNA2S9XqnzSrgghdns/Ln91eGyuUBTGand9PTtnWu8SseHHZYcPH/IurTqP 52qu5Urs2H9cruqVUNOT5D6kNYcrHnaEJoMtbK0CWISzNYRmZ3WfRnBjAPZgIWy8CsSvyFl3ZGqU w3ZO1YJ8v4mtl93iyGKfzcrDdnOTCI/0UaRgtwEMrV2x3/3SuB10eCFdE+vU3ENthN3pOqp2O/Dh JmH7Sbg0wTc21b41/OZXlcDvlySKPvsZ2xsV6U5fNCIbtvsCIHfI07ZbUOu0KNJYb5/xTF0tABCr Nqb6yjqhZzwp4zXJRPqwxkcuyqBMSATJrwQ5COQfszOoY+nWN7BxPCD3wUv6kPhFCXdbSMCyvelf JW7b1QncVYHc0rps1UhDjGg5RfMYYXY28ua1jK1mwaUflXBzg93BQfztfzvYOt3W3djq8dl4DK5m VF03xfdZld/Ost1Rs3EKfLVC0x88wN7/ERybH0io0Jd+dsh5UACBA5zGCc/QG0/OrioYEWAhkvAb RPC/rpWJj8WWXQoHC3NXLN50Bdyz+hBBV2I0G4spWlfCm075pAey1DQD2i1SeHQlJuP5gZZOx66Y JHQYM6/enetKnI3GB1oKhB1oqTsczg401R3O5wfa6rrzyl/1pLkjaG412rr+uN4MDqG4T2qLjKeT en0HZcBbIAhppmexPb9My4zCtQ24a8YcaX+u13EFTezZWyZsnlcf8RY2duSi1eLG2b6K6jSx0vGB 1WZj3g/KHKaUJTtJbZ+qtmXIpi91mX6f/fN3FQP++dvhipdibQXR1iqC90on+ENq10u7fUD4tqOi 3vnrOMq1GI/u+Mru/pCQrMsI7oqiAPvBj6IUbt7xG0Kczxbl6tm3SnUDVo5Xk9SZ502m4ihAQ+rK 38JlSubl9XVJ+YD5sPhZuG8dYeuYqjp09Qyk9T9yWtS/ttfyAk5InIpZR3LQIvCQzzYqqpz2/81i 8yJqh1Me/X5BrvPBM7sXfPyNoyxW8dJiVnVNvEmAyxTcbfRvHCaeN3Q/VKVEQKZ8Ac5m8MVgNhIx MoCtCIio9CNxBQ5w6xi+X1DWn/L3/wIAAP//AwBQSwMEFAAGAAgAAAAhAHLmNkAJBQAAYCEAABIA AAB3b3JkL251bWJlcmluZy54bWzMWt1u4jgUvl9p3wFF2suCE0IIaOgIAqy62hmNNF3tdQimRJPY kRNgejsvM4+wjzWvsMd2EhLy05JQNb0o1PY5Pv6Oz2ef4374+N33ekfMQpeSmaL2kdLDxKFblzzN lH8e13em0gsjm2xtjxI8U55xqHy8//23D6cpOfgbzGBgD3SQcHoKnJmyj6JgOhiEzh77dtj3XYfR kO6ivkP9Ad3tXAcPTpRtBxpSkfgWMOrgMAQ9lk2OdqjE6vyiNhpgAnPtKPPtKOxT9jTwbfbtENyB 9sCO3I3rudEz6EZGoobOlAMj09igu9QgLjKVBsUfiQQrrKJkXim5pM7BxyQSMw4Y9sAGSsK9G5yX 0VQbLHGfmHSsW8TR95Jxp0DVC/OlS36ND5bMPoErzgoL6krA2Eoh35M4cP+evXqpUUV1i4k9wlWk NrzGhPyciSW+7ZJUTTNosuBCSLTZ338yeghScwK3nbYH8i3VxSPzCsuQISIvu7TwKgWF0P26twOs 9Hxn+vBEKLM3Hlh0UvUe35HKPbCFvQkjZjvR54Pfy/31sJ0pSAwhobuFvqPtzZS1+BlbyoAL+wcv cv/GR+w9Pgc4GcM5w8OiWQ6L/MBLOudoqI/RxJQ93pF3uPCRTAakxqJksCpHAaOt/bRxix3Xt71U wSP+nvb9ofbT9r+cRI2Hd5FsDr4wbncEq44/kzEwhwLfAwqIq/pE4+MH55Eu4RBwRXE3/LW3yRMs daYMDRQPF/pBDBYkxDPovgi2WgX2UtreAOyVuZgv1OFcKugo2Bqa1IHNu28PtlYF9qo52Pp4ZRhD sXPEDgCru7azJ5pRgzXvvT3Uwyqo142hNlZjaz2ZxL7q5r429GEN1Lz39lBLSi/ytSn4qRFfr9WJ tlouW1DI5uB5OOZfcFWWrn/9+E/uAWh/N7o+TZk8FdiakigEr9ih48It4Ouzv6FwhwOmnwOmuQaX wEGwxTsbTsDYzUJLQ+4fVcSIGZ+ADbh/rJraSkMt6OjtHdeO+rvgOKPKcTHuDRw3tNQ5WuhdjrhW x0gX3Daucpvg7EZEuTSRqY+smGmbnElvHm+tjqQuuM2sclucTjSINl23rMUCkiGR0DRx29vnI+f8 IklcsukI7739VWJSBbW4rDeKELRcGeZI7/KJ1ArpLkSIWkzZtaU6NxajWmbbP2+Yu/3E03mPp/My GrJ5+0izVmgxLKU32H1R4EFdEOnIQgjJTPblTL494WXjYKzVxsGbeCef56k8DnNIiEt+BJVIKEAe ofRyA2RoylQ1N+YsLqquNwPGogfmYtb7jE+ZS/BFqwP1koum/UuX4zxqWgG1kWi5KWq/fvy8FjdN rSfWyg31LxSFeKEeas1p6pBvuw4guYnyAcY32o0BelUqlt1Ymgl5JV9iRR2sEqA2iVV+7+iFvdOF iINTpBkwl4Ek086L1vYRJ+Mru6G6EXH6sCGF56NLopZvuy7iRBksR+SS2t874kZwwL5zxI07GXGj cUOuvoituNBz0do+4uC19uJm0I2IM/SGFJ6PriYRB5Wyi9cReIIBlOA3f3qSN6XMiAf+ACPeoESy B+Iwkj+q5MRkXb9ULCnHlonJGnWpmEhXKmYrPKGdjRSFuwoxWe0rnS15SCozUtaaSsWSF5QyMVnr KBUb8ztRhZEy1y4VS94QymaTeWOp2KhmtjhvKZUTuXmFlWrNPgGdmeVJBfI/I+7/BwAA//8DAFBL AwQUAAYACAAAACEAUlF5aOAAAABVAQAAGAAoAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbCCiJAAo oCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckMFKxDAQhu+C7xDmnk26xFCXpovd bWGvouA1m6ZtoElKkooivrspntajp+GbYeb7mer4YWf0rkM03gkodhSQdsr3xo0CXl86XAKKSbpe zt5pAc7Dsb6/q/p46GWSMfmgL0lblBsm18tZwFfD27Y58Qdc7mmJWdsx3DSU49NTwSgrOvrI+Deg rHb5TBQwpbQcCIlq0lbGnV+0y8PBBytTxjASPwxG6bNXq9UukT2lnKg16+2bnaHe8vxuP+sh3uIW bQ3mv5aruc7Gj0Eu0yeQuiJ/VBvfvKL+AQAA//8DAFBLAwQUAAYACAAAACEAdD85esIAAAAoAQAA HgAIAWN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAITPwYoCMQwG4LvgO5Tcnc54EJHpeFkWvIm44LV0MjPFaVOaKPr2Fk8rLOwx Cfn+pN0/wqzumNlTNNBUNSiMjnofRwM/5+/VFhSLjb2dKaKBJzLsu+WiPeFspSzx5BOrokQ2MImk ndbsJgyWK0oYy2SgHKyUMo86WXe1I+p1XW90/m1A92GqQ28gH/oG1PmZSvL/Ng2Dd/hF7hYwyh8R 2t1YKFzCfMyUuMg2jygGvGB4t5qq3Au6a/XHf90LAAD//wMAUEsDBBQABgAIAAAAIQBs6td99gEA AO4DAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJxTwW7bMAy9D9g/GL43itN0DQJFRZGm6KFtgsVtz5xMJ8JkSZDUoNnXj4obx9l2mk/kI/34 /Ejzm49GZzv0QVkzy4vBMM/QSFsps5nlL+X9xSTPQgRTgbYGZ/keQ34jvn7hK28d+qgwZERhwizf xuimjAW5xQbCgMqGKrX1DURK/YbZulYS76x8b9BENhoOvzH8iGgqrC5cR5i3jNNd/F/SysqkL7yW e0eCBS+xcRoiiuckR3PWAby0EXSpGhQTgruEr2CDQRRDztqIv1lfBXE5viw4a2M+34IHGck+UUwm 11ToIfzWOa0kRLJWPCnpbbB1zJYHE7LEwFm/hZMxa5TvXsW9oLH9lD8qk9RcXXPWhqTPw8aD2wYx HieRXcrXEjTOyQBRgw7I2QngDwhpuStQJJrv4nSHMlqfBfWL1jvKsx8QMNk2y3fgFZhI9qW2NjnE 2oXoRamiJ26qtfkh7Lf1YzUW5A71UnDemMBWAxXO1dEEjWFZ07fFf4gt+mIPGlqpPTm9sJvxB+vc Ng7MXtx/v32eL7Jy8biYL59ok594sv5neHGlvUsH9OnoOdg7hDcVt2sHkrY1Go2u6KZOJ9Gr8TWd Dla04yPjCeAPZL/XaSy9azZYHXv+LqQje21/X1GMB0N6Dld1xOgwuv9K/AYAAP//AwBQSwMEFAAG AAgAAAAhAKnIXKqMAAAA2gAAABMAKABjdXN0b21YbWwvaXRlbTEueG1sIKIkACigIAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALJJsgrOLy1KTi1WCE7NSU0uSU0JLqnMSbVVinEMcNSL CPZRUgAL+CXmAgWBYkoKFbk5ecVWSbZKGSUlBVb6+sXJGam5icV6+QWpeUC5tPyi3MQSILcoXT8/ LS0zOdUlP7k0NzWvRN/IwMBMPykzKSczP70osSCjEmoYVYyys9GHe8aOlwsAAAD//wMAUEsDBBQA BgAIAAAAIQAm3pmS2wIAAB0MAAASAAAAd29yZC9mb250VGFibGUueG1s3JbRbpswFIbvJ+0dEPct xoGkjZpUbdZou1gvtky7dohJrGEb2SY0b79jDKFtyBKktdIWFCDH5mB/+c9v39w+8czbUqWZFBM/ vES+R0UiV0ysJ/6Pxfziyve0IWJFMinoxN9R7d9OP364KcepFEZ78LzQY55M/I0x+TgIdLKhnOhL mVMBjalUnBj4qdYBJ+pXkV8kkufEsCXLmNkFGKGhX6dR52SRacoS+kkmBafCVM8HimaQUQq9Yblu spXnZCulWuVKJlRrmDPPXD5OmNinCaODRJwlSmqZmkuYTOBGFNhU8HiIqjue+R5Pxl/WQiqyzIBd GUb+tAbnlWNBOAS/7/hSZlU8J0JqGkLTlmQTH8VwhMgmHKEhXGM08gObINkQpanZd8QunBLOsl0T VZIT4RpyZpJNE98Sxex4XJNma2go9BLBC+uP7yIh6OFlBB/0GbyMJFWeq2dPQQTy7DPD8AOnnAMQ C8ap9h5p6X2rRm47vCaCgcIQDYBEBF8Md1E3EfR3iDzAwPHdfN4SmUFkdBWFdaQlcl1HOolU8w9d nvOJzGShGFWWSac+MOhigK6Bg9UGBiZ9aHC5oqpLICl7oqtDdRxlMXgPFj+hOK0p6U4ScSOw9tqt i85KIYWRrvs/USgzkrGlYp0gMJpXUrCSiEAccO4G0VkgumRa9yJhRYHw8wKJIHA320faAmlK5g8F cl0V2vkF8plmW2pYQrw4fuYaJDOP4K2N4d0zKrZUFNRbLOrJvTJaWIKAGpiJnQ0wQ72o9ZaP80c8 al2lei+cDiqpiRyHhlAF9nxod2D/3esNRvfgrhEAaI63F0+nu76Lo7TiGcbeV7piBT9SUrBBqUrJ /kv/uTgWZAOL7xEOTh1u9bUqeWN1wOYDP+yNBHYRdu0dovj+dZXgU2tviPqvvYSDxx4jYXcfjoNT Rh8S/fdl3SaLoj2b1mRP+0V40mTrDZqe/gYAAP//AwBQSwMEFAAGAAgAAAAhAN/3qEV/AQAATAMA ABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbJRTUU/CMBB+N/E/LH2HbgJiFgYJIRgTY4ziD+i6bjS2 vaYtTPj1Hhsgig/w1Ovd9329u28bTb60itbCeQkmI0k3JpEwHAppqox8LOadBxL5wEzBFBiRkY3w ZDK+vRnVaS3ydxECIn2EKsanmmdkGYJNKfV8KTTzXbDCYLEEp1nAq6uoZu5zZTsctGVB5lLJsKF3 cXxP9jLuEhUoS8nFDPhKCxMaPnVCoSIYv5TWH9TqS9RqcIV1wIX3OI9WrZ5m0hxlkv6ZkJbcgYcy dHEY2nZEd1JIT+Im0opEmqdPlQHHcoUbrJM+GeP6Crn2+zOqU1lkpDfoDYe9ZDBs6jkUm5lcY23N FFpD6A6Ny3sWZThk42P2TVbLf9ILsOfYKYQA+k8e+5kWbvdG+OEYNJ0g0G8zgp8GBpZxHKKJOShA r9gqQNuGOunsOmb+q6PruO508muotDGhGboNx6P2bHwBG6SWWzEHN3VQe+EaA5hSUL++POIFwSf/ wPgbAAD//wMAUEsDBBQABgAIAAAAIQCIcIDQugoAAMRAAAAaAAAAd29yZC9zdHlsZXNXaXRoRWZm ZWN0cy54bWzUW9ty2zgSfd+q/QeW3h2LulqqUaYcxxm7yvF4Iqf2GaIgi2WK5PBixfmj+Y75sW2A IAiyCYiQxjXJiyVT6APgoE/jwsYvv37bBc4LTVI/Chc9912/59DQi9Z++LTofX38dHbRc9KMhGsS RCFd9F5p2vv1/X//88t+nmavAU0dAAjT+T72Fr1tlsXz8/PU29IdSd/tfC+J0miTvfOi3Xm02fge Pd9Hyfp80Hf7/FucRB5NU6jtioQvJO0JuB1Gi2IaQl2bKNmRLH0XJU/nO5I85/EZoMck81d+4Gev gN2flDDRopcn4Vw06Ew2iJnMiwaJj9IiQb1oqbew/Bh5+Y6GGa/xPKEBtCEK060fV904Fg26uC2b 9GLqxMsuKMvtY3eE6pNd7jIGHxOyh6GoABFcCxnrwmgXFDyw8a1GtYno9k2dESPCIGQbujShXmfZ kh3xQwlzHDUquaCHU/z7tyTKY9mc2D8N7TZ8llhMlhYt60+48tSupVYASLrLLYlpz9l589unMErI KoAW7d2Rwzyy9x5CxTryPtINyYMsZf8mD4n4V/zHPz5FYZY6+zlJPR/oefR3EF3u6d75Eu0IjOR+ TkmaXaY+eYT4AlXsfKjt5jJMffbjln1pNfOgf020c1ZlQMInsHwhwaJHw7OvS7US5dHKXwMySc6W lz0wPOc9KD+VnsSyX0WpRrchQEC4WBZhE0ihm7vIe6brZQY/LHoQevnDr7cPiR8lEMuqZ0u682/8 9ZpCkJblwq2/pv/b0vBrStfV8z8+8RApHnhRHmaL3mAy5SMRpOvrbx6NWaiC6kLCiLxnBhBH9vM/ S1uXdRQYaiu+pYTND45rbTGwthhaW4ysLcbWFjDBWHI1tbaAideyjllnC49wB2DlU8Wz+IDmDbfq PsqPfhZAHOjY6mW+yuwMsiRik1NH/OtdvCWpD3NxR4Obx893zkNCixVGRmEO2s9zvxLjbGYQxUNA PLqNgjVNnEf6LWPGmNuuaPeRs4yJxyfjeiO6D8ed/7TNHAjOTKzNvkz6hr4Ulnd+ynuhUjAxxYXC 7LfER8xNBobaPtO1n+/KhhZRpVbnsLsxDzA149FhY9bRlmrHHS1xnZPDloylljqnHS1xnRcdLXlA rTFk8uqPsMJ22hxhavKfqyiIkk0elGPadL6pyYukcWu1JkeSlm0uODV5UU0qzqXnwTzdMjqmPlea 0dubul2JR29v6nxTRXoUExENlIEepbOu9BAmgX2hLz7bk54WRrmyH0hCnhISw4aqHkqHI/ak05Ln jzzK+NSmKmfQfcK9DWHpl1KnFWfIV3Sd2iHGh/fLMDidA5B+cDpHIj1E55Ckh+gUm7TmVkFKj2KS rYw5fEh0kWNqUq6E4HOCFsIk29b4hecIu/iF7U1E4PiF7U0sNCKPWw4HRjER0UCREsEo1vELQ5ji V6tQMYS1UDGEtVAxhLVQMYSVUJH5UULFKCb/lCpThYohTC4qIVShYgiTf7YKFS/J7ISK7U1EYKFi exMLDYlJoWIUExENFClUjGItVAxhLVQMYS1UDGEtVAxhLVQMYSVUZH6UUDGKyT+lylShYgiTi0oI VagYwuSfrULl60V1BdhxF13OZdjeRAQWKrY3sdCQmBQqRjER0UCRQsUo1kLFENZCxRDWQsUQ1kLF ENZCxRBWQkXmRwkVo5j8U6pMFSqGMLmohFCFiiFM/tkqVH6ie4JQsb2JCCxUbG9ioSExKVSMYiKi gSKFilGshYohrIWKIayFiiGshYohrIWKIayEisyPEipGMfmnVJkqVAxhclEJoQoVQ5j8s1Wo/EXK CULF9iYisFCxvYmFhsSkUDGKiYgGihQqRrEWKoawFiqGsBYqhrAWKoawFiqGsBIqMj9KqBjF5J9S ZapQMYTJRSWEKlQMYfJP9mIuoI76/kxVqGt/6qmDGnR/mSUa9YVuaAIJShSd5XaHKs9i9Vh8T9/p PPZDFD078r2nStOQ7ze6gfirwI/4EfXrwfPuIX+TjF/S6l/XP/5+5dwUr+wPo/PBxejonBxyINR0 BpYrwPPBoGD2GkNOQayeukOqA0v+gAQz3gKWAXELGQsi74AZs0QEsOWpGOIx75EgkH+HJLV1Wabf Hw5H/WsRFSChhIEkjRSSGxq80Mz3iDMeV1kkIlGk5UdeS/r9imWh8JYMygisJIpskrNPX1g3ymyU Re/79uzqnr1/UzJDOBsHaOFlGBHgQQl1eYKGSkSVaMFbtiKQ5/E7S9tANIXwxrnteTf6IG+FtfSZ 0vgegAoaitfPALpib8RhRAcj/p6CbDIKWXLl1jfKs8AP6d1LUNbPD6+ACYHaHBuWjXOZ+JBvUnSq +HuV8s9nmsj+DUWcS7+XyNWTaoiKZycRP9ASL1rwkxDPp5Yjifc5/b4YhorygVBYTRX82UmUD7WU i5npJ6GcO4iecpHKVoWaydgpln8sgKBAVPvVqBNlgMTyrDZA/NlJA1Tk7bUFIxESf5IB4u70BgPU EruUMXkb0Yy1ohGr/Lcek/ToOYE7DRqGVS32a0PQ23j4RMumqO/HZZMP9wE2FW+U82g1aw7KwMVn Z4CyX64U+aRtEULs9n5c/srwWF+hKIyV7no8Oxda7xKx4cdlhw8f8i6tOk/naqblSuzYf1yuypVQ 3ZPkPqQxhysedoImvS1srTxYhLM1hGZn9RAFcNkG9mBr2HhliF+Rs+7I1CiH7ZyKBXm1iS2X3eLI ospm5WG7vkmER/ookrErAYbWPrLfSW7cDjq8kK6JZWruoTbC7nQVFLsd+HIbsv3kXmTKF/vW9TdS VAK/X9Eg+EwStjfKolhfNKAbtvsCILfP07YbUKsoy6Kd3j7hmbpaACBWbUzxL+uEnvEw361oIvJ+ NT5ymXt5SANIfqXIQSD/mJ1BnUq3voG14wG5D176TyHJcrhLRT2W7e3/meO2XZ/BzR7ILS3LFo00 xIiGU9SPEaYXg+GslLHVLLgkQQ43N9idL8Rf9dvB1um27sZWjy5GI3A1o+raKX5Iivx2lu2Omo1T 4IsVmv7gAfb+z+DY/EBChb4iySHnQQEEDnBqJzz94Wh8cV3AiAALkYTfIILPslYmPhZb4ggOFmau WLzpCrgX5SGCrsRgOhJTtK7EcDLhkx7IUtMMaLdI4dGVGI9mB1o6GbliktBhTIfl7lxX4mIwOtBS IOxAS91+f3qgqW5/NjvQVtedFf6qJ80dQHOL0db1xx1O4RCK+6S2yGgyLtd3UAa8BYKQZnoW2/Or KE98uLYBd82YI1Xnes1LY/Cj2LM3TNg8rz7iLaztyEWrxY2zqoriNLHQ8YHVZm3e9/IUppQlO0lt nqo2ZcimL3WZ/pD8/VcRA/7+y+GKl2JtBNHGKoL3Sif4Q2rXS7t5QPi2o6Le+Ws5yrUYj/b4yu7+ 0DVd5QFcjkYB9gMJgghu3vEbQpzPBuXq2bdKdQ1Wjled1OlwOJ6IowANqY9kC5cpmZeX1yXlA+bD 4mfhvlCKx/UypqoOXTwDaf1DTov61/RaXsBZU6dg1pEcNAg85LO1igqn/bdZrF9EbXHKk98vyHU+ eGb7go+/cZTFCl4azKquiTcJcJmCu43+jcN4OOy7H4pSIiD7fAHOZvBFbzoQMdKDrQiIKCeBuAIH uGUMrxaU5bf0/f8BAAD//wMAUEsDBBQABgAIAAAAIQB3XUOdWAEAAI0CAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMkk1qwzAUhPeF3sFo b8tKQn+E7UBbsmqgkJSW7oT0kohaspCUODlSz9GLVbYT16FZFLyRZ96nmWdn070qox1YJyudI5Kk KALNKyH1Okevy1l8hyLnmRasrDTk6AAOTYvrq4wbyisLL7YyYL0EFwWSdpSbHG28NxRjxzegmEuC QwdxVVnFfDjaNTaMf7I14FGa3mAFngnmGW6AsemJ6IgUvEearS1bgOAYSlCgvcMkIfjX68Eqd3Gg VQZOJf3BhE7HuEO24J3Yu/dO9sa6rpN63MYI+Ql+nz8v2qqx1M2uOKAiE5xyC8xXtlj47y+zYRqi sK2t8xkeiM0iS+b8POx8JUE8HC74/3qaMQs72Xy34jbDw2O4u63aBQARhfC0q3pS3saPT8sZKkYp mcQkDc+SjGl6T9P0o4l3Nt+U6V6oY8h/Eid0RM6JJ0DRJj7/gYofAAAA//8DAFBLAQItABQABgAI AAAAIQBJn4PiqwEAAJcGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAA5AMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhACpCyRBDAQAAzAQAABwAAAAAAAAAAAAAAAAACAcAAHdvcmQvX3JlbHMvZG9j dW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAJamPmyKFAAAy0gwAEQAAAAAAAAAAAAAAAACN CQAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAlrWt4pYGAABQGwAAFQAAAAAAAAAA AAAAAADejgAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAHCdT3EHBgAA1hEA ABEAAAAAAAAAAAAAAAAAp5UAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAB9lmZEt CgAA0z0AAA8AAAAAAAAAAAAAAAAA3ZsAAHdvcmQvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQBy 5jZACQUAAGAhAAASAAAAAAAAAAAAAAAAADemAAB3b3JkL251bWJlcmluZy54bWxQSwECLQAUAAYA CAAAACEAUlF5aOAAAABVAQAAGAAAAAAAAAAAAAAAAABwqwAAY3VzdG9tWG1sL2l0ZW1Qcm9wczEu eG1sUEsBAi0AFAAGAAgAAAAhAHQ/OXrCAAAAKAEAAB4AAAAAAAAAAAAAAAAArqwAAGN1c3RvbVht bC9fcmVscy9pdGVtMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBs6td99gEAAO4DAAAQAAAAAAAA AAAAAAAAALSuAABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhAKnIXKqMAAAA2gAAABMA AAAAAAAAAAAAAAAA4LEAAGN1c3RvbVhtbC9pdGVtMS54bWxQSwECLQAUAAYACAAAACEAJt6ZktsC AAAdDAAAEgAAAAAAAAAAAAAAAADFsgAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAh AN/3qEV/AQAATAMAABQAAAAAAAAAAAAAAAAA0LUAAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0A FAAGAAgAAAAhAIhwgNC6CgAAxEAAABoAAAAAAAAAAAAAAAAAgbcAAHdvcmQvc3R5bGVzV2l0aEVm ZmVjdHMueG1sUEsBAi0AFAAGAAgAAAAhAHddQ51YAQAAjQIAABEAAAAAAAAAAAAAAAAAc8IAAGRv Y1Byb3BzL2NvcmUueG1sUEsFBgAAAAAQABAAHAQAAALFAAAAAA== --_002_2842AD9A45C83B44B57635FD4831E60A0C1D3C8APEXCVZYM14corpo_-- From nobody Fri Oct 10 09:47:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0840B1A1F70 for ; Fri, 10 Oct 2014 09:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYw4VP5Uv9pQ for ; Fri, 10 Oct 2014 09:47:30 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947841A8A39 for ; Fri, 10 Oct 2014 09:41:45 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so3655238lab.16 for ; Fri, 10 Oct 2014 09:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ab+GhQnWZJcnI/WqO+grALO1txSjh/vQrDX3P5cTtEs=; b=vWIKgvtRkJc6boBZRY8ZsWYf0lzhbNGfiLhLyFnkdoeerqcGz51fNdsE8zD4fF6E6N 9XOS9uyy830ex407aLo+hWmJJMuqQoTc7LOXvznC7z4XEAgf3mOdPTGTQ2feGbiRUpVj WrhoWQsf6KIe2Mjbzg5ymF/y0sL4hBVRXgKNS+Baf5ONI+i5X4Qx6/F7Azm6Q4aj45z4 p/XP0N7V87E/mbccbQgjce59WDA6hECSuMS8DJrZle7ExOq19j7iZ0JP1Taf7o4HWgAh epRinuK03WaoZLAYY1F/n009cf4+IspomDvm8Rs2UJPp26s+3QB/9hvcQ7PM2Vw3/7Bh qRGg== MIME-Version: 1.0 X-Received: by 10.112.140.137 with SMTP id rg9mr4647442lbb.93.1412958927474; Fri, 10 Oct 2014 09:35:27 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Fri, 10 Oct 2014 09:35:27 -0700 (PDT) In-Reply-To: <5437BA7C.6060402@alvestrand.no> References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> <5437BA7C.6060402@alvestrand.no> Date: Fri, 10 Oct 2014 09:35:27 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EK_twYuyyPT1PsYMxkGNOsC5hXg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 16:47:31 -0000 On 10 October 2014 03:52, Harald Alvestrand wrote: > I'd like the chairs to indicate whether or not they are going to entertain > -gateways for WG draft status too. Maybe you should instead ask the working group. From nobody Fri Oct 10 09:59:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1480E1A3BA5 for ; Fri, 10 Oct 2014 09:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxyjPloKMUOW for ; Fri, 10 Oct 2014 09:58:56 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id BF7961A3BA2 for ; Fri, 10 Oct 2014 09:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7B40B7C35E8; Fri, 10 Oct 2014 18:58:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC1gOUdWMGal; Fri, 10 Oct 2014 18:58:53 +0200 (CEST) Received: from [172.30.42.85] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1B3107C32F2; Fri, 10 Oct 2014 18:58:53 +0200 (CEST) Message-ID: <5438104B.7080008@alvestrand.no> Date: Fri, 10 Oct 2014 18:58:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Martin Thomson References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> <5437BA7C.6060402@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l9_HJzvZT4GEpXzd6CfOmFr2IbE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 16:58:59 -0000 On 10/10/2014 06:35 PM, Martin Thomson wrote: > On 10 October 2014 03:52, Harald Alvestrand wrote: >> I'd like the chairs to indicate whether or not they are going to entertain >> -gateways for WG draft status too. > Maybe you should instead ask the working group. That's the question I think it's the WG chairs' job to ask. -- Surveillance is pervasive. Go Dark. From nobody Fri Oct 10 10:13:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80BF1A8A70 for ; Fri, 10 Oct 2014 10:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns-tjk-hDRfJ for ; Fri, 10 Oct 2014 10:13:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4601A8A9A for ; Fri, 10 Oct 2014 10:13:12 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-2a-543813a68577 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 27.61.21334.6A318345; Fri, 10 Oct 2014 19:13:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 19:13:10 +0200 From: Christer Holmberg To: Harald Alvestrand , Martin Thomson Thread-Topic: [rtcweb] Dates for rtcweb drafts Thread-Index: AQHP5HhS9ZK86AC2VUyZOQnH4dJIZZwpZe2AgAAGiYCAACV0MA== Date: Fri, 10 Oct 2014 17:13:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4750CA@ESESSMB209.ericsson.se> References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> <5437BA7C.6060402@alvestrand.no> <5438104B.7080008@alvestrand.no> In-Reply-To: <5438104B.7080008@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje4yYYsQg477lhbH+rrYLK6d+cdo sfZfO7sDs8eVCVdYPXbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujNY5k1kL5rNXdLdNY2pg /MbaxcjBISFgIrHhYWkXIyeQKSZx4d56ti5GLg4hgaOMEj+vnYByljBKtDeuYANpYBOwkOj+ pw3SICIQKbF24Tt2EJtZQF3izuJzYLawgK7Es8efWSFq9CSat/9kh7CdJPb/e8YCYrMIqErs +9cLNpJXwFfi3kIJiFXHGCW2bd7ADhLnBJrT81oIpJwR6Lbvp9YwQawSl7j1ZD4TxM0CEkv2 nGeGsEUlXj7+xwphK0k0LnnCClGvI7Fg9yc2CFtbYtnC12D1vAKCEidnPmGZwCg2C8nYWUha ZiFpmYWkZQEjyypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwHg6uOW37g7G1a8dDzEKcDAq 8fA+KDUPEWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjP2R 6WbJNy/4n93wnyN63bRtm7iyUnUa3seXuzx1eZ/NWxx90ypFvETX9llz25OWlP5WptmsnCKy sR+fSvxfe8ep8zRzUcZUgd+n77DaWRinGvxTul92tM2vcf+D7wttn4g7ysic+Hemi491dfa3 s+dX7PbLiUjd77M0c78OR2K95rMQleULlViKMxINtZiLihMBDtob0YgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/K4KeXFKsAVs_ylxGXkLH6R0vfT0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 17:13:39 -0000 While you try to figure out who should ask the question, I'll give MY answe= r: I think the draft should be adopted as a WG item :) Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: 10 October 2014 19:59 To: Martin Thomson Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Dates for rtcweb drafts On 10/10/2014 06:35 PM, Martin Thomson wrote: > On 10 October 2014 03:52, Harald Alvestrand wrote: >> I'd like the chairs to indicate whether or not they are going to=20 >> entertain -gateways for WG draft status too. > Maybe you should instead ask the working group. That's the question I think it's the WG chairs' job to ask. -- Surveillance is pervasive. Go Dark. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Oct 10 10:38:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09111A9043 for ; Fri, 10 Oct 2014 10:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5iBRJJWyHN3 for ; Fri, 10 Oct 2014 10:38:44 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073411A9029 for ; Fri, 10 Oct 2014 10:38:44 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj1so2168179pad.15 for ; Fri, 10 Oct 2014 10:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3e9fZ5CbfilFp/AXKj553Yg2Eu8rnVhLTwmEl9E3Y3I=; b=aATq4KUMDHOcM9ns5JC0HbHbhUQJz7WetehmkcYGZAQbR0lvfpUOkR1b6uXU3pCgzg cVifChgGloTnndcc0Aw/oCMlibp6DZ9xMZTi8vHC1SMuaAg9FD+vd/+Mqtx8I+2eXU1x vVQ5vNt7ozvl8rq9jGHfyDkwkIBu1mF2/rNU3fnvty0YEO5KTL7qN/5K8ny40LYNVr5Y 8pUTeu4kMiM5rv9H2V0PmYH6nK++ecv8A13Rz1XZUcqNLDkZHYKSXUoNYrY1lMQOW/76 KfMBI8hFoULNto/J9mU5IyhDVWjNw71CfoW+/+0JxM1bC77OwHyMzD+mFs+9UxHf7T0O nC0w== X-Received: by 10.70.44.73 with SMTP id c9mr6890480pdm.11.1412962723654; Fri, 10 Oct 2014 10:38:43 -0700 (PDT) Received: from [192.168.1.104] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by mx.google.com with ESMTPSA id qs4sm3994969pbb.90.2014.10.10.10.38.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Oct 2014 10:38:42 -0700 (PDT) References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> <5437BA7C.6060402@alvestrand.no> <5438104B.7080008@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4750CA@ESESSMB209.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4750CA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <866C6993-A4D0-4261-845C-DD420413453E@gmail.com> X-Mailer: iPad Mail (12A405) From: Bernard Aboba Date: Fri, 10 Oct 2014 10:38:46 -0700 To: Christer Holmberg Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/unME9ug4buA6_rOHBzrOsO7UKgA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 17:38:45 -0000 +1. > On Oct 10, 2014, at 10:13, Christer Holmberg wrote: >=20 > While you try to figure out who should ask the question, I'll give MY answ= er: I think the draft should be adopted as a WG item :) >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestra= nd > Sent: 10 October 2014 19:59 > To: Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Dates for rtcweb drafts >=20 >> On 10/10/2014 06:35 PM, Martin Thomson wrote: >>> On 10 October 2014 03:52, Harald Alvestrand wrote= : >>> I'd like the chairs to indicate whether or not they are going to=20 >>> entertain -gateways for WG draft status too. >> Maybe you should instead ask the working group. >=20 > That's the question I think it's the WG chairs' job to ask. >=20 >=20 > -- > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > 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 nobody Fri Oct 10 12:12:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916AE1ACE5E for ; Fri, 10 Oct 2014 12:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oY1vDk_vkry for ; Fri, 10 Oct 2014 12:12:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0681.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::681]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1186E1ACE53 for ; Fri, 10 Oct 2014 12:12:17 -0700 (PDT) Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Fri, 10 Oct 2014 19:11:55 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1044.008; Fri, 10 Oct 2014 19:11:55 +0000 From: "Wyss, Felix" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVA Date: Fri, 10 Oct 2014 19:11:54 +0000 Message-ID: <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> In-Reply-To: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.147.12.61] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1579; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(199003)(13464003)(189002)(51704005)(64706001)(105586002)(66066001)(4396001)(50986999)(54356999)(106116001)(107886001)(92566001)(122556002)(46102003)(40100003)(20776003)(106356001)(86362001)(85306004)(99286002)(95666004)(107046002)(19580395003)(33646002)(120916001)(85852003)(76576001)(19580405001)(101416001)(99396003)(76176999)(97736003)(230783001)(2656002)(87936001)(2351001)(76482002)(110136001)(15975445006)(31966008)(77096002)(108616004)(74316001)(15202345003)(80022003)(21056001)(2501002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1579; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NzB2uJsGl663kHWAgTWLsFofoHY Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 19:12:20 -0000 I'm sorry for being a bit late to the party, but I have a concern about sec= tion 6.5 allowing use of the DTLS role for picking the SCTP stream identifi= ers (odd vs. even). It's an abstraction leak and complicates the implemen= tation of middleboxes. The DTLS role is determined during the connection e= stablishment, so a middlebox that manages connections with two endpoints to= record the media passing through it can't guarantee that one side is the D= TLS server and the other the DTLS client because in its offers it is requir= ed to specify a=3Dsetup:actpass (see RFC#5763). That means it's at the mer= cy of the endpoint as to which DTLS role they pick. Worse, it is desirable= for the answerers to pick 'active' as that can speed up the DTLS negotiati= on. =20 I feel it would be better to explicitly require that applications are respo= nsible for identifier collision avoidance instead of allowing them to rely = on the DTLS roles.=20 Thanks, --Felix Wyss Interactive Intelligence, Inc. > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of The IESG > Sent: Thursday, October 09, 2014 20:49 > To: IETF-Announce > Cc: rtcweb@ietf.org > Subject: [rtcweb] Last Call: (Web= RTC > Data Channels) to Proposed Standard >=20 >=20 > The IESG has received a request from the Real-Time Communication in WEB- > browsers WG (rtcweb) to consider the following document: > - 'WebRTC Data Channels' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-10-23. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginnin= g of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > The WebRTC framework specifies protocol support for direct > interactive rich communication using audio, video, and data between > two peers' web-browsers. This document specifies the non-media data > transport aspects of the WebRTC framework. It provides an > architectural overview of how the Stream Control Transmission > Protocol (SCTP) is used in the WebRTC context as a generic transport > service allowing WEB-browsers to exchange generic data from peer to > peer. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Oct 10 13:33:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CCB1AD06A for ; Fri, 10 Oct 2014 13:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUJ-93xsNJmQ for ; Fri, 10 Oct 2014 13:33:49 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFBD1AD062 for ; Fri, 10 Oct 2014 13:33:48 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id q1so3993419lam.18 for ; Fri, 10 Oct 2014 13:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OSeAxu13fxQ6LAWJI5sgAWO1FN47iRcWwFP8emKIj9E=; b=TVwjGHxf0RXCOT5YGWfH8Yp3j+ycGto2M+QdDvHwa7y4R8XvcJvFJp5NEfrkx+MVm/ dDI0taOphLUXP1Goqa80BWu0iRBCb0iMeFx2AhH/ws2mH685p8v3K+OI5dlkbOH1F1WH 3bwtVDR8pWKYWNOa9RNFRS+rsbIuVbGiyoE712t79rD7uSSzlAvPTaZT9SGeOaiAy+1L rCVUM4Sk2sJOIBc/PVNr29NVbnLwqOq+HfbOHf9X4hBPF8y6Q8JXNi4Vm8XVukz2oLdw qKU/VpCfpB7M9k1FyCCndeNh2jDW00obR5rEfRr6eMlHKX6Tw87cEq9TfkYXA9x+5DIy rdBQ== MIME-Version: 1.0 X-Received: by 10.152.3.167 with SMTP id d7mr7347726lad.17.1412973226315; Fri, 10 Oct 2014 13:33:46 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Fri, 10 Oct 2014 13:33:46 -0700 (PDT) In-Reply-To: <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> Date: Fri, 10 Oct 2014 13:33:46 -0700 Message-ID: From: Martin Thomson To: "Wyss, Felix" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/62glyGSHAPqAKYcACv37djw09G4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 20:33:51 -0000 On 10 October 2014 12:11, Wyss, Felix wrote: > I feel it would be better to explicitly require that applications are responsible for identifier collision avoidance instead of allowing them to rely on the DTLS roles. Are you suggesting that we might want to consider the effect of a MitM attack on the robustness of this? From nobody Fri Oct 10 13:52:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC121AD2D5 for ; Fri, 10 Oct 2014 13:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17wJaIU-Xd9J for ; Fri, 10 Oct 2014 13:52:43 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEB11AD259 for ; Fri, 10 Oct 2014 13:52:43 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so3199276wiv.3 for ; Fri, 10 Oct 2014 13:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3duJZOC/tz1OnUks9U86lkVtLG6lZSYWj+TxZ5vSpic=; b=0E/s1npZHLaiWtj5JUFmHQ5Tt+1LfWABXFFd56UPS2mQXbw/U1uihuZZzEY33oeN1q HM7uuzEwSahv6wwcq7ZRBExORLA5W45Q6wiilF6oREvE/TOnvA76AWB+6apiLIZjA1aA ScWZ/A2uOzR12/RE33JGVW9j/ya4HnLCJHFoeIK2ibvFf3tSvWKqO6MCMjn46LsjuGY+ PcmajQVQ9TBoaxxoclyErz7zHC17QC6yxVoLs++j25Tey1bd0AC8d3nQUTzqf/xWhaVH UfGqy9LMCiMPATddqC5ah+F2G+WOVCwbzWsF5sXuyWLLKPfFsub9YELxz2bpcTvlTh4F nmfw== MIME-Version: 1.0 X-Received: by 10.180.85.41 with SMTP id e9mr7123445wiz.21.1412974362198; Fri, 10 Oct 2014 13:52:42 -0700 (PDT) Received: by 10.194.60.134 with HTTP; Fri, 10 Oct 2014 13:52:42 -0700 (PDT) Date: Fri, 10 Oct 2014 13:52:42 -0700 Message-ID: From: Suhas Nandakumar To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d043bd8eeef8735050517ba3c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hyWNlgB6CCMuePgPOwy3JCkWNQA Subject: [rtcweb] New Draft: draft-nandakumar-mmusic-proto-iana-registration X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 20:52:45 -0000 --f46d043bd8eeef8735050517ba3c Content-Type: text/plain; charset=UTF-8 Hello All Here is the link to MMUSIC SDP draft that registers new proto attributes for RTP/TCP for TLS and SAVP(F) variants. http://tools.ietf.org/html/draft-nandakumar-mmusic-proto-iana-registration-00 This plan is move all these variants into a MMUSIC draft instead of defining it in the JSEP going further Look forward for the feedback Cheers Suhas --f46d043bd8eeef8735050517ba3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

Here is the link to MMUSIC SD= P draft that registers new proto attributes for RTP/TCP for TLS and SAVP(F)= variants.


This plan is move all these variants into a MMUS= IC draft instead of defining it in the JSEP going further


Look forward for the feedback

Cheers
Suhas
--f46d043bd8eeef8735050517ba3c-- From nobody Fri Oct 10 14:46:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C711A8851; Fri, 10 Oct 2014 14:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y16yTIBhngjb; Fri, 10 Oct 2014 14:46:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 963C01A8842; Fri, 10 Oct 2014 14:46:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141010214609.7784.10149.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 14:46:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zvcUeN3WbXQUQCuZR1IpzpSS7v4 Cc: rtcweb@ietf.org Subject: [rtcweb] Last Call: (WebRTC Data Channel Establishment Protocol) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 10 Oct 2014 21:46:11 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Data Channel Establishment Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies a simple protocol for establishing symmetric Data Channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Oct 11 00:21:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5861A001E for ; Sat, 11 Oct 2014 00:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7MbXd6q5Npd for ; Sat, 11 Oct 2014 00:21:30 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0054.outbound.protection.outlook.com [65.55.169.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA371A001D for ; Sat, 11 Oct 2014 00:21:30 -0700 (PDT) Received: from CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) by CY1PR0501MB1259.namprd05.prod.outlook.com (25.160.225.17) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 11 Oct 2014 07:21:28 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 11 Oct 2014 07:21:27 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1049.012; Sat, 11 Oct 2014 07:21:27 +0000 From: "Wyss, Felix" To: Martin Thomson Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYA== Date: Sat, 11 Oct 2014 07:21:26 +0000 Message-ID: <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.147.12.61] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1578;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(164054003)(189002)(13464003)(199003)(95666004)(99286002)(99396003)(105586002)(97736003)(122556002)(4396001)(74316001)(87936001)(85852003)(2656002)(230783001)(77096002)(86362001)(76482002)(92566001)(120916001)(107046002)(80022003)(46102003)(106356001)(76576001)(106116001)(108616004)(110136001)(33646002)(85306004)(31966008)(76176999)(54356999)(101416001)(50986999)(21056001)(64706001)(66066001)(20776003)(19580405001)(19580395003)(40100003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1578; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1259; X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Jtp1_cC6QOPtjUFi3H8Ql0dF0-A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 07:21:32 -0000 SSdtIG5vdCBsb29raW5nIGF0IHRoaXMgaW4gdGVybXMgb2YgTWl0TSBhdHRhY2tzIGJ1dCBmb3Ig dG9wb2xvZ2llcyB3aGVyZSB3ZSB3YW50IHRvIGhhdmUgYmFjay10by1iYWNrIFdlYlJUQyBzZXNz aW9ucyBnb2luZyB0aHJvdWdoIGEgbGVnaXRpbWF0ZSBtaWRkbGVib3guICBUaGF0IG1pZGRsZWJv eCBwYXNzZXMgdGhlIG1lZGlhIGFuZCBkYXRhIGJldHdlZW4gdGhlc2Ugc2Vzc2lvbnMgd2hpbGUg cmVjb3JkaW5nIGFuZC9vciBwZXJmb3JtaW5nIGFuYWx5dGljcyBvbiBpdC4gIFJlcXVpcmluZyB0 aGUgbWlkZGxlYm94IHRvIHdvcnJ5IGFib3V0IGhvdyB0aGUgdHdvIGVuZHBvaW50cyBtaWdodCBw aWNrIFNDVFAgc3RyZWFtIGlkZW50aWZpZXJzIGFuZCBwb3NzaWJseSBoYXZpbmcgdG8gbWFwIG9y IHJld3JpdGUgdGhlbSB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVzIHRoZWlyIGltcGxlbWVudGF0 aW9uLiAgDQoNCklNSE8gZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGRhdGEgY2hhbm5lbHMs IHRoZSBEVExTIGxheWVyIHNob3VsZCBiZSBhbiBvcGFxdWUgdHVubmVsICgiYnVtcCBpbiB0aGUg c3RhY2siKSB0aGF0IHBhc3NlcyBwYWNrZXRzIGJldHdlZW4gZW5kcG9pbnRzLiAgVGhlIERUTFMg cm9sZSBvZiBhbiBlbmRwb2ludCB0aGF0IGVtZXJnZXMgZHVyaW5nIGNvbm5lY3Rpb24gZXN0YWJs aXNobWVudCBzaG91bGQgbm90IGJlIHJlbGV2YW50IHRvIHRoZSBvcGVyYXRpb24gb2YgdGhlIGRh dGEgY2hhbm5lbHMuICBIZW5jZSBteSBjb25jZXJucyBhYm91dCB0aGUgYWJzdHJhY3Rpb24gbGVh ay4gIA0KDQpUaGFua3MsDQotLUZlbGl4DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21d DQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxMCwgMjAxNCAxNjozNA0KPiBUbzogV3lzcywgRmVs aXgNCj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gTGFzdCBD YWxsOiA8ZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsLTEyLnR4dD4NCj4gKFdlYlJUQyBE YXRhIENoYW5uZWxzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gT24gMTAgT2N0b2JlciAy MDE0IDEyOjExLCBXeXNzLCBGZWxpeCA8RmVsaXguV3lzc0BpbmluLmNvbT4gd3JvdGU6DQo+ID4g SSBmZWVsIGl0IHdvdWxkIGJlIGJldHRlciB0byBleHBsaWNpdGx5IHJlcXVpcmUgdGhhdCBhcHBs aWNhdGlvbnMgYXJlDQo+IHJlc3BvbnNpYmxlIGZvciBpZGVudGlmaWVyIGNvbGxpc2lvbiBhdm9p ZGFuY2UgaW5zdGVhZCBvZiBhbGxvd2luZyB0aGVtIHRvIHJlbHkNCj4gb24gdGhlIERUTFMgcm9s ZXMuDQo+IA0KPiBBcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB3ZSBtaWdodCB3YW50IHRvIGNvbnNp ZGVyIHRoZSBlZmZlY3Qgb2YgYSBNaXRNDQo+IGF0dGFjayBvbiB0aGUgcm9idXN0bmVzcyBvZiB0 aGlzPw0K From nobody Sat Oct 11 00:41:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770D01A0055 for ; Sat, 11 Oct 2014 00:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGmnGRJ74VwA for ; Sat, 11 Oct 2014 00:41:40 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60D91A004B for ; Sat, 11 Oct 2014 00:41:39 -0700 (PDT) Received: from [192.168.1.104] (p508F121A.dip0.t-ipconnect.de [80.143.18.26]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DA40A1C1050E0; Sat, 11 Oct 2014 09:41:36 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> Date: Sat, 11 Oct 2014 09:41:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> To: "Wyss, Felix" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yanl33b_om_x-y9b8uyIGAZTdVw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 07:41:42 -0000 On 11 Oct 2014, at 09:21, Wyss, Felix wrote: > I'm not looking at this in terms of MitM attacks but for topologies = where we want to have back-to-back WebRTC sessions going through a = legitimate middlebox. That middlebox passes the media and data between = these sessions while recording and/or performing analytics on it. = Requiring the=20 So doesn't it terminate the DTLS connections of both peers? Best regards Michael > middlebox to worry about how the two endpoints might pick SCTP stream = identifiers and possibly having to map or rewrite them unnecessarily = complicates their implementation. =20 >=20 > IMHO from the perspective of the data channels, the DTLS layer should = be an opaque tunnel ("bump in the stack") that passes packets between = endpoints. The DTLS role of an endpoint that emerges during connection = establishment should not be relevant to the operation of the data = channels. Hence my concerns about the abstraction leak. =20 >=20 > Thanks, > --Felix >=20 >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Friday, October 10, 2014 16:34 >> To: Wyss, Felix >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Last Call: = >> (WebRTC Data Channels) to Proposed Standard >>=20 >> On 10 October 2014 12:11, Wyss, Felix wrote: >>> I feel it would be better to explicitly require that applications = are >> responsible for identifier collision avoidance instead of allowing = them to rely >> on the DTLS roles. >>=20 >> Are you suggesting that we might want to consider the effect of a = MitM >> attack on the robustness of this? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Sat Oct 11 00:55:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F831A0062 for ; Sat, 11 Oct 2014 00:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KlRKfoE2nFs for ; Sat, 11 Oct 2014 00:55:46 -0700 (PDT) Received: from vsp-authed-04-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFF21A005F for ; Sat, 11 Oct 2014 00:55:46 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-04-02.binero.net (Halon Mail Gateway) with ESMTPS; Sat, 11 Oct 2014 09:55:31 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id B9C9C3A181; Sat, 11 Oct 2014 09:55:36 +0200 (CEST) Message-ID: <5438E276.9080404@omnitor.se> Date: Sat, 11 Oct 2014 09:55:34 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Tuexen References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <03CCB2BC-068F-4A52-9ECE-6F8AE8E21D7D@lurchi.franken.de> In-Reply-To: <03CCB2BC-068F-4A52-9ECE-6F8AE8E21D7D@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XMlvdsYkw5f1d7bT9jZVFPEAJNY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 07:55:48 -0000 On 2014-09-28 23:49, Michael Tuexen wrote: > On 16 Aug 2014, at 08:44, Gunnar Hellstrom wrote: > >> We have discussed the lack of description of failure handling in draft-ietf-rtcweb-data-channel a couple of times. >> >> Explanations of mechanisms have been provided in mail answers that I have not seen documented elsewhere, but they have not been introduced in the draft. >> >> I think that for specification and implementation of the WebRTC API, there is a need for clear specification how the channels behave in failure situations. >> >> I suggest to insert a new chapter 6.7 in the draft with the following contents. >> >> -------------------------------------------------------------------Proposed new section 6.7------------------------------------------------------------------------------------------- >> 6.7 Transmission failure and error handling >> >> Failures can occur in an open channel by transmission error detection and by SCTP watchdog error indications. >> If transmission in a reliable channel fails, the association where the channel belongs will be aborted. If all retries for a watchdog expires, the corresponding association will be aborted. All channels in an association that is aborted because of errors need to be closed by the party detecting the failure. Network error indications shall be provided to upper layers on all closed channels. >> >> If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with other data items. A transmission error indication SHALL be provided to upper layers on that channel. >> >> If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel, and provide an transmission error indication to upper layers. >> >> If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel. >> -----------------------------------------------------------------------end of proposal--------------------------------------------------------------------------------------------------------------- >> >> I am not sure about what the two last kinds of errors should result in and hope that the experts can adjust the wording. > Hi Gunnar, > > I think I have covered the contents your are suggesting, but I added some of the text in a section called SCTP Association Management. > > Please let me know if the new revision addresses your comments. Yes, I think that in version -12, there is sufficient indication of the behavior in failure situations. Thanks, /Gunnar > > Best regards > Michael >> Regards >> >> Gunnar >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> >> On 2014-08-11 20:13, IESG Secretary wrote: >>> The IESG would like to retract the current Last Call on the following >>> document: >>> >>> - 'WebRTC Data Channels' >>> as Proposed Standard >>> >>> The document's state has been set back to "AD Evaluation." >>> >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sat Oct 11 02:59:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9564D1A01E1 for ; Sat, 11 Oct 2014 02:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAB_fMh3NL37 for ; Sat, 11 Oct 2014 02:59:22 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175AA1A01D8 for ; Sat, 11 Oct 2014 02:59:21 -0700 (PDT) Received: (qmail 39174 invoked from network); 11 Oct 2014 09:59:19 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 1219 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 11 Oct 2014 09:59:19 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 79B2018A0B9A; Sat, 11 Oct 2014 10:59:19 +0100 (BST) Received: from [192.168.157.34] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 3521518A0242; Sat, 11 Oct 2014 10:59:19 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8428B698-3512-4570-90F9-C5E74B3D6C98" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> Date: Sat, 11 Oct 2014 10:59:20 +0100 Message-Id: <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5o8M79npjENTcnDFVK2ULP1ejd4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 09:59:24 -0000 --Apple-Mail=_8428B698-3512-4570-90F9-C5E74B3D6C98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 11 Oct 2014, at 08:41, Michael Tuexen = wrote: > On 11 Oct 2014, at 09:21, Wyss, Felix wrote: >=20 >> I'm not looking at this in terms of MitM attacks but for topologies = where we want to have back-to-back WebRTC sessions going through a = legitimate middlebox. That middlebox passes the media and data between = these sessions while recording and/or performing analytics on it. = Requiring the=20 > So doesn't it terminate the DTLS connections of both peers? Yes, it does. I think the worry is that the middle box may end up as = DTLS server to both legs. That leaves both endpoints as DTLS clients. This then breaks the = odd-even split and risks the endpoints allocating the same stream numbers. For this to happen you have to have a middle box that offers actpass to = both endpoints, agrees to passive=20 on both legs and then proceeds to terminate the DTLS but bridge the = SCTP. Which only works if it also re-writes the signalling fingerprints =91correctly' too. Tim. >=20 > Best regards > Michael >> middlebox to worry about how the two endpoints might pick SCTP stream = identifiers and possibly having to map or rewrite them unnecessarily = complicates their implementation. =20 >>=20 >> IMHO from the perspective of the data channels, the DTLS layer should = be an opaque tunnel ("bump in the stack") that passes packets between = endpoints. The DTLS role of an endpoint that emerges during connection = establishment should not be relevant to the operation of the data = channels. Hence my concerns about the abstraction leak. =20 >>=20 >> Thanks, >> --Felix >>=20 >>> -----Original Message----- >>> From: Martin Thomson [mailto:martin.thomson@gmail.com] >>> Sent: Friday, October 10, 2014 16:34 >>> To: Wyss, Felix >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] Last Call: = >>> (WebRTC Data Channels) to Proposed Standard >>>=20 >>> On 10 October 2014 12:11, Wyss, Felix wrote: >>>> I feel it would be better to explicitly require that applications = are >>> responsible for identifier collision avoidance instead of allowing = them to rely >>> on the DTLS roles. >>>=20 >>> Are you suggesting that we might want to consider the effect of a = MitM >>> attack on the robustness of this? >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_8428B698-3512-4570-90F9-C5E74B3D6C98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 11 Oct 2014, at 08:41, Michael = Tuexen <Michael.Tuexen@lurchi.fra= nken.de> wrote:

On 11 Oct 2014, at 09:21, Wyss, Felix = <Felix.Wyss@inin.com> = wrote:

I'm not looking at this in terms = of MitM attacks but for topologies where we want to have back-to-back = WebRTC sessions going through a legitimate middlebox.  That = middlebox passes the media and data between these sessions while = recording and/or performing analytics on it.  Requiring the 
So doesn't = it terminate the DTLS connections of both = peers?

Yes, it does. I think = the worry is that the middle box may end up as DTLS server to both = legs.
That leaves both endpoints as DTLS clients. This then = breaks the odd-even split and risks the endpoints = allocating
the same stream = numbers.

For this to happen you have to have a = middle box that offers actpass to both endpoints, agrees to = passive 
on both legs and then proceeds to terminate the = DTLS but bridge the SCTP. Which only works if it = also
re-writes the signalling fingerprints =91correctly' = too.

Tim.



Best = regards
Michael
middlebox to worry about = how the two endpoints might pick SCTP stream identifiers and possibly = having to map or rewrite them unnecessarily complicates their = implementation.  

IMHO from the perspective of the data = channels, the DTLS layer should be an opaque tunnel ("bump in the = stack") that passes packets between endpoints.  The DTLS role of an = endpoint that emerges during connection establishment should not be = relevant to the operation of the data channels.  Hence my concerns = about the abstraction leak. =  

Thanks,
--Felix

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Friday, October 10, 2014 16:34
To: Wyss, Felix
Cc: rtcweb@ietf.org
Subject: Re: = [rtcweb] Last Call: = <draft-ietf-rtcweb-data-channel-12.txt>
(WebRTC Data Channels) = to Proposed Standard

On 10 October 2014 12:11, Wyss, Felix <Felix.Wyss@inin.com> = wrote:
I feel it would be better to = explicitly require that applications are
responsible for = identifier collision avoidance instead of allowing them to rely
on = the DTLS roles.

Are you suggesting that we might want to consider = the effect of a MitM
attack on the robustness of = this?
_______________________________________________
r= tcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb


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

= --Apple-Mail=_8428B698-3512-4570-90F9-C5E74B3D6C98-- From nobody Sat Oct 11 08:06:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBF81A6EFC for ; Sat, 11 Oct 2014 08:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WXXCa3kzygY for ; Sat, 11 Oct 2014 08:06:02 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974AC1A6EFB for ; Sat, 11 Oct 2014 08:06:02 -0700 (PDT) Received: from [192.168.1.104] (p508F1388.dip0.t-ipconnect.de [80.143.19.136]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C2D161C0E96E9; Sat, 11 Oct 2014 17:05:59 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> Date: Sat, 11 Oct 2014 17:05:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> To: tim panton X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q-z9WVewFv0CtALSm1FD75VeMRc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 15:06:06 -0000 On 11 Oct 2014, at 11:59, tim panton wrote: >=20 > On 11 Oct 2014, at 08:41, Michael Tuexen = wrote: >=20 >> On 11 Oct 2014, at 09:21, Wyss, Felix wrote: >>=20 >>> I'm not looking at this in terms of MitM attacks but for topologies = where we want to have back-to-back WebRTC sessions going through a = legitimate middlebox. That middlebox passes the media and data between = these sessions while recording and/or performing analytics on it. = Requiring the=20 >> So doesn't it terminate the DTLS connections of both peers? >=20 > Yes, it does. I think the worry is that the middle box may end up as = DTLS server to both legs. And why can't the middle box avoid this? > That leaves both endpoints as DTLS clients. This then breaks the = odd-even split and risks the endpoints allocating > the same stream numbers. I think "risks" is the wrong term here. I guess they will run into this = almost always. Best regards Michael >=20 > For this to happen you have to have a middle box that offers actpass = to both endpoints, agrees to passive=20 > on both legs and then proceeds to terminate the DTLS but bridge the = SCTP. Which only works if it also > re-writes the signalling fingerprints =91correctly' too. >=20 > Tim. >=20 >=20 >>=20 >> Best regards >> Michael >>> middlebox to worry about how the two endpoints might pick SCTP = stream identifiers and possibly having to map or rewrite them = unnecessarily complicates their implementation. =20 >>>=20 >>> IMHO from the perspective of the data channels, the DTLS layer = should be an opaque tunnel ("bump in the stack") that passes packets = between endpoints. The DTLS role of an endpoint that emerges during = connection establishment should not be relevant to the operation of the = data channels. Hence my concerns about the abstraction leak. =20 >>>=20 >>> Thanks, >>> --Felix >>>=20 >>>> -----Original Message----- >>>> From: Martin Thomson [mailto:martin.thomson@gmail.com] >>>> Sent: Friday, October 10, 2014 16:34 >>>> To: Wyss, Felix >>>> Cc: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Last Call: = >>>> (WebRTC Data Channels) to Proposed Standard >>>>=20 >>>> On 10 October 2014 12:11, Wyss, Felix wrote: >>>>> I feel it would be better to explicitly require that applications = are >>>> responsible for identifier collision avoidance instead of allowing = them to rely >>>> on the DTLS roles. >>>>=20 >>>> Are you suggesting that we might want to consider the effect of a = MitM >>>> attack on the robustness of this? >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Sat Oct 11 09:59:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090E01A6FBB for ; Sat, 11 Oct 2014 09:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdL7XT66V6rI for ; Sat, 11 Oct 2014 09:59:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0687.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::687]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B091A6FC1 for ; Sat, 11 Oct 2014 09:59:13 -0700 (PDT) Received: from CY1PR0501MB1577.namprd05.prod.outlook.com (25.161.161.151) by CY1PR0501MB1290.namprd05.prod.outlook.com (25.160.225.24) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 11 Oct 2014 16:58:50 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1577.namprd05.prod.outlook.com (25.161.161.151) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 11 Oct 2014 16:58:48 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1049.012; Sat, 11 Oct 2014 16:58:48 +0000 From: "Wyss, Felix" To: Michael Tuexen , tim panton Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYIAADzmAgAAmfQCAAFWsAIAAG4cg Date: Sat, 11 Oct 2014 16:58:48 +0000 Message-ID: References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.147.12.61] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1577;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(51704005)(87936001)(77096002)(85306004)(93886004)(54356999)(106116001)(76176999)(86362001)(105586002)(2656002)(92566001)(80022003)(122556002)(21056001)(46102003)(230783001)(74316001)(4396001)(33646002)(50986999)(106356001)(107046002)(85852003)(108616004)(95666004)(99286002)(97736003)(120916001)(76576001)(99396003)(66066001)(76482002)(20776003)(31966008)(64706001)(101416001)(40100003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1577; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1290; X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LSvM-i3ob-DTTGkyDNGSDLYOKC4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 16:59:35 -0000 > > Yes, it does. I think the worry is that the middle box may end up as DT= LS server to both legs. > And why can't the middle box avoid this? How can it if it is the offerer on both legs? From RFC#5763, section 5 (pa= ge 10): "The endpoint that is the offerer MUST use the setup attribute valu= e of setup:actpass and be prepared to receive a client_hello before it rece= ives the answer." The answerer thus gets to pick whether it is the client or server. As ment= ioned in my original message, the answerer picking client is desirable as i= t can speed up the DTLS negotiation. So almost invariably the middlebox wi= ll be DTLS server on both legs. > > That leaves both endpoints as DTLS clients. This then breaks the > > odd-even split and risks the endpoints allocating the same stream numbe= rs. > I think "risks" is the wrong term here. I guess they will run into this a= lmost always. Not necessarily if the endpoints draw their IDs at random. That makes this= particularly problematic as everything may appear to work fine but then fa= il intermittently in the field due to collisions. =20 --Felix From nobody Sat Oct 11 10:25:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10C01A6FDA for ; Sat, 11 Oct 2014 10:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc5g83SJYh6O for ; Sat, 11 Oct 2014 10:25:16 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF5D1A6FC2 for ; Sat, 11 Oct 2014 10:25:15 -0700 (PDT) Received: from [192.168.1.104] (p508F1388.dip0.t-ipconnect.de [80.143.19.136]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 420D01C0E96E9; Sat, 11 Oct 2014 19:25:13 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Sat, 11 Oct 2014 19:25:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C812CD7-E488-4C08-973A-F85AFED22F15@lurchi.franken.de> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> To: "Wyss, Felix" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ATaxTACxCG4Y23ouHpyiz1JsR9Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 17:25:16 -0000 On 11 Oct 2014, at 18:58, Wyss, Felix wrote: >>> Yes, it does. I think the worry is that the middle box may end up as = DTLS server to both legs. >> And why can't the middle box avoid this? >=20 > How can it if it is the offerer on both legs? =46rom RFC#5763, = section 5 (page 10): "The endpoint that is the offerer MUST use the = setup attribute value of setup:actpass and be prepared to receive a = client_hello before it receives the answer." OK, I see. >=20 > The answerer thus gets to pick whether it is the client or server. As = mentioned in my original message, the answerer picking client is = desirable as it can speed up the DTLS negotiation. So almost invariably = the middlebox will be DTLS server on both legs. Makes sense. >=20 >=20 >>> That leaves both endpoints as DTLS clients. This then breaks the >>> odd-even split and risks the endpoints allocating the same stream = numbers. >> I think "risks" is the wrong term here. I guess they will run into = this almost always. >=20 > Not necessarily if the endpoints draw their IDs at random. That makes = this particularly problematic as everything may appear to work fine but = then fail intermittently in the field due to collisions. =20 As far as I know the browsers currently don't use random values. They = start from small IDs and increment. Since your middlebox is terminating DTLS, I think you could also = terminate both SCTP associations. But I guess you want to avoid that. So can't you just rewrite the stream IDs? Best regards Michael >=20 > --Felix >=20 >=20 From nobody Sat Oct 11 10:30:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BF51A6FD5 for ; Sat, 11 Oct 2014 10:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo93jp5ZHsxa for ; Sat, 11 Oct 2014 10:30:19 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C34C1A6FC2 for ; Sat, 11 Oct 2014 10:30:19 -0700 (PDT) Received: from [192.168.1.104] (p508F1388.dip0.t-ipconnect.de [80.143.19.136]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3B4421C0E96E9; Sat, 11 Oct 2014 19:30:17 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <4C812CD7-E488-4C08-973A-F85AFED22F15@lurchi.franken.de> Date: Sat, 11 Oct 2014 19:30:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <751705D3-49CF-4A63-9B6A-ACFCC9E74617@lurchi.franken.de> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <4C812CD7-E488-4C08-973A-F85AFED22F15@lurchi.franken.de> To: "Wyss, Felix" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jG8geDOcZMCc-XmD0dsurqmti70 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 17:30:20 -0000 On 11 Oct 2014, at 19:25, Michael Tuexen = wrote: > On 11 Oct 2014, at 18:58, Wyss, Felix wrote: >=20 >>>> Yes, it does. I think the worry is that the middle box may end up = as DTLS server to both legs. >>> And why can't the middle box avoid this? >>=20 >> How can it if it is the offerer on both legs? =46rom RFC#5763, = section 5 (page 10): "The endpoint that is the offerer MUST use the = setup attribute value of setup:actpass and be prepared to receive a = client_hello before it receives the answer." > OK, I see. >>=20 >> The answerer thus gets to pick whether it is the client or server. = As mentioned in my original message, the answerer picking client is = desirable as it can speed up the DTLS negotiation. So almost invariably = the middlebox will be DTLS server on both legs. > Makes sense. >>=20 >>=20 >>>> That leaves both endpoints as DTLS clients. This then breaks the >>>> odd-even split and risks the endpoints allocating the same stream = numbers. >>> I think "risks" is the wrong term here. I guess they will run into = this almost always. >>=20 >> Not necessarily if the endpoints draw their IDs at random. That = makes this particularly problematic as everything may appear to work = fine but then fail intermittently in the field due to collisions. =20 > As far as I know the browsers currently don't use random values. They = start from small IDs and increment. > Since your middlebox is terminating DTLS, I think you could also = terminate both SCTP associations. But I guess > you want to avoid that. So can't you just rewrite the stream IDs? My fault: You can't. Both sides might derive something from the ID = locally seen and assume it is the same on the other end... Best regards Michael >=20 > Best regards > Michael >>=20 >> --Felix >>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Sun Oct 12 03:18:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6A91A8A50 for ; Sun, 12 Oct 2014 03:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7b_OIMgZIyn for ; Sun, 12 Oct 2014 03:18:27 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 475C11A8A4D for ; Sun, 12 Oct 2014 03:18:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 667B77C4026 for ; Sun, 12 Oct 2014 12:18:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Iwfyz4lPMRQ for ; Sun, 12 Oct 2014 12:18:25 +0200 (CEST) Received: from [172.30.42.116] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 75AE17C39A0 for ; Sun, 12 Oct 2014 12:18:25 +0200 (CEST) Message-ID: <543A5570.7060208@alvestrand.no> Date: Sun, 12 Oct 2014 12:18:24 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/f63AZLMsKQegGvs9Wuayfr9tCxw Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 10:18:30 -0000 Given that the middle box has to: - decrypt and encrypt all packets (because the keys are different) - assert its own identity towards both endpoints (because otherwise DTLS doesn't work) - be trusted by both endpoints (otherwise it's a MITM attack by definition) - manage SCTP congestion control independently on the two legs (because that's how SCTP works) I don't see the reshuffling of packets between channel numbers to be an excessive *additional* burden. The kind of "middle box" that "just shuffles bits" while doing something to them or with them in addition doesn't exist in the WebRTC context. On 10/11/2014 06:58 PM, Wyss, Felix wrote: >>> Yes, it does. I think the worry is that the middle box may end up as DTLS server to both legs. >> And why can't the middle box avoid this? > How can it if it is the offerer on both legs? From RFC#5763, section 5 (page 10): "The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer." > > The answerer thus gets to pick whether it is the client or server. As mentioned in my original message, the answerer picking client is desirable as it can speed up the DTLS negotiation. So almost invariably the middlebox will be DTLS server on both legs. > > >>> That leaves both endpoints as DTLS clients. This then breaks the >>> odd-even split and risks the endpoints allocating the same stream numbers. >> I think "risks" is the wrong term here. I guess they will run into this almost always. > Not necessarily if the endpoints draw their IDs at random. That makes this particularly problematic as everything may appear to work fine but then fail intermittently in the field due to collisions. > > --Felix > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Sun Oct 12 06:23:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6691A1B73 for ; Sun, 12 Oct 2014 06:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfbMYHPytnop for ; Sun, 12 Oct 2014 06:23:05 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B7E1A0235 for ; Sun, 12 Oct 2014 06:23:04 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 67D55EFA6F33E; Sun, 12 Oct 2014 13:23:01 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9CDN1AW016649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Oct 2014 09:23:03 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sun, 12 Oct 2014 09:23:01 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CP1MhvaILuEckCrzly7+3a5apwp9uEAgAAW3wCAALT1AIAABaGAgAA5NeKAAGJ7AIABInYA///vOAA= Date: Sun, 12 Oct 2014 13:23:00 +0000 Message-ID: References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> In-Reply-To: <543A5570.7060208@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/i9mF8Zag_n80_dxRh2TeJ_Nu0N8 Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 13:23:07 -0000 > Given that the middle box has to: >=20 > - decrypt and encrypt all packets (because the keys are different) > - assert its own identity towards both endpoints (because otherwise DTLS > doesn't work) > - be trusted by both endpoints (otherwise it's a MITM attack by definitio= n) > - manage SCTP congestion control independently on the two legs (because > that's how SCTP works) >=20 > I don't see the reshuffling of packets between channel numbers to be an > excessive *additional* burden. >=20 > The kind of "middle box" that "just shuffles bits" while doing something > to them or with them in addition doesn't exist in the WebRTC context. [Raju]=20 +1. Also, such a middle box can even go with Out-of-band negotiation (instead o= f inband DCEP with odd/even rule)=20 of stream ids, in which case stream ids are selected by the application and= odd/even rule does not apply. BR Raju From nobody Sun Oct 12 06:30:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763531A1B7F for ; Sun, 12 Oct 2014 06:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erBsVkPOvU2N for ; Sun, 12 Oct 2014 06:30:49 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008D51A1B80 for ; Sun, 12 Oct 2014 06:30:48 -0700 (PDT) Received: from [192.168.1.200] (p508F1AC6.dip0.t-ipconnect.de [80.143.26.198]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 65B891C0B2E31; Sun, 12 Oct 2014 15:30:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <543A5570.7060208@alvestrand.no> Date: Sun, 12 Oct 2014 15:30:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tvGQ8HDMMAHrK8ir1wdOWvJx8eI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 13:30:51 -0000 On 12 Oct 2014, at 12:18, Harald Alvestrand = wrote: > Given that the middle box has to: >=20 > - decrypt and encrypt all packets (because the keys are different) > - assert its own identity towards both endpoints (because otherwise = DTLS > doesn't work) > - be trusted by both endpoints (otherwise it's a MITM attack by = definition) > - manage SCTP congestion control independently on the two legs = (because > that's how SCTP works) >=20 > I don't see the reshuffling of packets between channel numbers to be = an > excessive *additional* burden. I agree CPU wise. But I have a question: Don't expect both endpoints of = a data channel to see the same "id" attribute? And isn't this attribute the stream ID? So can conceptually a middlebox map the streams IDs? Best regards Michael=20 >=20 > The kind of "middle box" that "just shuffles bits" while doing = something > to them or with them in addition doesn't exist in the WebRTC context. >=20 >=20 > On 10/11/2014 06:58 PM, Wyss, Felix wrote: >>>> Yes, it does. I think the worry is that the middle box may end up = as DTLS server to both legs. >>> And why can't the middle box avoid this? >> How can it if it is the offerer on both legs? =46rom RFC#5763, = section 5 (page 10): "The endpoint that is the offerer MUST use the = setup attribute value of setup:actpass and be prepared to receive a = client_hello before it receives the answer." >>=20 >> The answerer thus gets to pick whether it is the client or server. = As mentioned in my original message, the answerer picking client is = desirable as it can speed up the DTLS negotiation. So almost invariably = the middlebox will be DTLS server on both legs. >>=20 >>=20 >>>> That leaves both endpoints as DTLS clients. This then breaks the >>>> odd-even split and risks the endpoints allocating the same stream = numbers. >>> I think "risks" is the wrong term here. I guess they will run into = this almost always. >> Not necessarily if the endpoints draw their IDs at random. That = makes this particularly problematic as everything may appear to work = fine but then fail intermittently in the field due to collisions. =20 >>=20 >> --Felix >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Sun Oct 12 08:16:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59911A1A37 for ; Sun, 12 Oct 2014 08:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdHAtWLjx1et for ; Sun, 12 Oct 2014 08:16:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0692.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::692]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00431A1B34 for ; Sun, 12 Oct 2014 08:16:05 -0700 (PDT) Received: from CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) by CY1PR0501MB1529.namprd05.prod.outlook.com (25.161.161.139) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sun, 12 Oct 2014 15:15:43 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sun, 12 Oct 2014 15:15:41 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1049.012; Sun, 12 Oct 2014 15:15:41 +0000 From: "Wyss, Felix" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYIAADzmAgAAmfQCAAFWsAIAAG4cggAEmdgCAAEBzwA== Date: Sun, 12 Oct 2014 15:15:39 +0000 Message-ID: <7d1a8bc1a73a48688746c0da01d0e78a@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> In-Reply-To: <543A5570.7060208@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.147.12.61] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1578;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(199003)(189002)(50986999)(21056001)(76176999)(54356999)(101416001)(66066001)(20776003)(40100003)(31966008)(64706001)(122556002)(74316001)(2656002)(4396001)(87936001)(95666004)(99286002)(2501002)(97736003)(99396003)(105586002)(76576001)(106116001)(106356001)(93886004)(85852003)(85306004)(108616004)(33646002)(86362001)(77096002)(76482002)(230783001)(92566001)(80022003)(107046002)(107886001)(120916001)(46102003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1578; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1529; X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2c7sPSFOu9JqMhCtAXe8B37AEmc Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 15:16:09 -0000 > Given that the middle box has to: >=20 > - decrypt and encrypt all packets (because the keys are different) > - assert its own identity towards both endpoints (because otherwise DTLS = doesn't work) > - be trusted by both endpoints (otherwise it's a MITM attack by definitio= n) All these are not relevant with respect to how the SCTP packets get from on= e WebRTC endpoint to the other. That's really all the data channels care a= bout. The rest is opaque to them, assumed a given and the concern of other= layers in the WebRTC stack. > - manage SCTP congestion control independently on the two legs (because t= hat's how SCTP works) Can you please elaborate on why you believe that's required? As I understa= nd it, from SCTP's perspective in WebRTC DTLS represents the IP layer. Doe= sn't that mean congestion control is strictly above DTLS and SCTP should no= t care about how many hops its packets go through and whether any of these = hops decrypt/re-encrypt the packets or pass them on as-is?=20 > I don't see the reshuffling of packets between channel numbers to be an e= xcessive *additional* burden. I respectfully disagree as it adds unnecessary complexity. Michael further= more has made a good argument on why it's not that simple. To add to his c= oncerns: are we certain that none of the application protocols using the da= ta channels will ever reference stream IDs of one SCTP stream in the data o= f another SCTP stream? If that ever were the case, the middlebox would hav= e to understand these application protocols and rewrite the stream data, no= t just the SCTP packets.=20 I furthermore have still not seen a convincing argument for requiring this = abstraction leak from the lower level by using the DTLS role for something = unrelated to DTLS' purpose. Whether an endpoint started as server or clien= t is completely irrelevant to the payload data transported over it. While = it may be a seemingly convenient hack to avoid explicit conflict resolution= , abstraction leaks like that invariably have unintended consequences--as w= e can see here. =20 > The kind of "middle box" that "just shuffles bits" while doing something = to them or with them in addition doesn't exist in the WebRTC context. Well, then it should. I presented a use-case of a middlebox that records a= nd/or performs analytics of the WebRTC session media. That is a common app= lication in VoIP.=20 --Felix =09 From nobody Sun Oct 12 08:28:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E271A1BA0 for ; Sun, 12 Oct 2014 08:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17zgrT8aSNph for ; Sun, 12 Oct 2014 08:28:22 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id D00501A1B36 for ; Sun, 12 Oct 2014 08:28:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EB95D7C4032; Sun, 12 Oct 2014 17:28:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLzpy0xSoMuh; Sun, 12 Oct 2014 17:28:20 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:9850:582a:f95e:5dc]) by mork.alvestrand.no (Postfix) with ESMTPSA id EFBE17C4031; Sun, 12 Oct 2014 17:28:19 +0200 (CEST) Message-ID: <543A9E11.2030605@alvestrand.no> Date: Sun, 12 Oct 2014 17:28:17 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Michael Tuexen References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jPXXRLvvQG7J-UJevrwmOJ90Ils Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 15:28:25 -0000 On 10/12/2014 03:30 PM, Michael Tuexen wrote: > On 12 Oct 2014, at 12:18, Harald Alvestrand wrote: > >> Given that the middle box has to: >> >> - decrypt and encrypt all packets (because the keys are different) >> - assert its own identity towards both endpoints (because otherwise DTLS >> doesn't work) >> - be trusted by both endpoints (otherwise it's a MITM attack by definition) >> - manage SCTP congestion control independently on the two legs (because >> that's how SCTP works) >> >> I don't see the reshuffling of packets between channel numbers to be an >> excessive *additional* burden. > I agree CPU wise. But I have a question: Don't expect both endpoints of a > data channel to see the same "id" attribute? And isn't this attribute > the stream ID? So can conceptually a middlebox map the streams IDs? The two ends don't see the same identity either, so the middle box is not transparent. The application has to know the middle box is there. So it has to be written to deal with differing numbers at the two ends too. From nobody Sun Oct 12 09:50:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BF01A6F05 for ; Sun, 12 Oct 2014 09:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4w0IGzp4oh0 for ; Sun, 12 Oct 2014 09:50:54 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC021A6F68 for ; Sun, 12 Oct 2014 09:50:53 -0700 (PDT) Received: from [192.168.1.200] (p508F1AC6.dip0.t-ipconnect.de [80.143.26.198]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0648D1C104DF2; Sun, 12 Oct 2014 18:50:48 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <543A9E11.2030605@alvestrand.no> Date: Sun, 12 Oct 2014 18:50:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/55AWWSfDlFW-LiRL_Lchnejz8h4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 16:50:56 -0000 On 12 Oct 2014, at 17:28, Harald Alvestrand = wrote: > On 10/12/2014 03:30 PM, Michael Tuexen wrote: >> On 12 Oct 2014, at 12:18, Harald Alvestrand = wrote: >>=20 >>> Given that the middle box has to: >>>=20 >>> - decrypt and encrypt all packets (because the keys are different) >>> - assert its own identity towards both endpoints (because otherwise = DTLS >>> doesn't work) >>> - be trusted by both endpoints (otherwise it's a MITM attack by = definition) >>> - manage SCTP congestion control independently on the two legs = (because >>> that's how SCTP works) >>>=20 >>> I don't see the reshuffling of packets between channel numbers to be = an >>> excessive *additional* burden. >> I agree CPU wise. But I have a question: Don't expect both endpoints = of a >> data channel to see the same "id" attribute? And isn't this attribute >> the stream ID? So can conceptually a middlebox map the streams IDs? >=20 > The two ends don't see the same identity either, so the middle box is = not transparent. OK. So this means that the ID defined in=20 http://w3c.github.io/webrtc-pc/#widl-RTCDataChannel-id doesn't have to be the same on both ends, right? It would be useful to make that clear in the document. I always assumed that they are the = same on both ends... Best regards Michael >=20 > The application has to know the middle box is there. So it has to be = written to deal with differing numbers at the two ends too. >=20 >=20 >=20 From nobody Sun Oct 12 10:46:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7381A6F91 for ; Sun, 12 Oct 2014 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8IsSnnFC_WF for ; Sun, 12 Oct 2014 10:46:22 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA7F1A1A77 for ; Sun, 12 Oct 2014 10:46:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 684B57C4032; Sun, 12 Oct 2014 19:46:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCS_9a4lpY07; Sun, 12 Oct 2014 19:46:19 +0200 (CEST) Received: from [172.30.42.85] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 571A17C4031; Sun, 12 Oct 2014 19:46:19 +0200 (CEST) Message-ID: <543ABE69.8030104@alvestrand.no> Date: Sun, 12 Oct 2014 19:46:17 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Michael Tuexen References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DcjS1XlXH56O6wBDs5An0mPbtOk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 17:46:25 -0000 On 10/12/2014 06:50 PM, Michael Tuexen wrote: > On 12 Oct 2014, at 17:28, Harald Alvestrand wrote: > >> On 10/12/2014 03:30 PM, Michael Tuexen wrote: >>> On 12 Oct 2014, at 12:18, Harald Alvestrand wrote: >>> >>>> Given that the middle box has to: >>>> >>>> - decrypt and encrypt all packets (because the keys are different) >>>> - assert its own identity towards both endpoints (because otherwise DTLS >>>> doesn't work) >>>> - be trusted by both endpoints (otherwise it's a MITM attack by definition) >>>> - manage SCTP congestion control independently on the two legs (because >>>> that's how SCTP works) >>>> >>>> I don't see the reshuffling of packets between channel numbers to be an >>>> excessive *additional* burden. >>> I agree CPU wise. But I have a question: Don't expect both endpoints of a >>> data channel to see the same "id" attribute? And isn't this attribute >>> the stream ID? So can conceptually a middlebox map the streams IDs? >> The two ends don't see the same identity either, so the middle box is not transparent. > OK. So this means that the ID defined in > http://w3c.github.io/webrtc-pc/#widl-RTCDataChannel-id > doesn't have to be the same on both ends, right? It has to be the same on both ends of the SCTP connection. It's just that (I think) you can't splice SCTP connections together; either you terminate them, or you don't. That's my understanding - YMMV. > It would be useful > to make that clear in the document. I always assumed that they are the same > on both ends... > > Best regards > Michael >> The application has to know the middle box is there. So it has to be written to deal with differing numbers at the two ends too. >> >> >> -- Surveillance is pervasive. Go Dark. From nobody Sun Oct 12 11:51:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6237D1A7022 for ; Sun, 12 Oct 2014 11:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lLd-2aP8bG0 for ; Sun, 12 Oct 2014 11:51:41 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1896F1A7021 for ; Sun, 12 Oct 2014 11:51:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E70147C4032 for ; Sun, 12 Oct 2014 20:51:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tSUxq1SZtl5 for ; Sun, 12 Oct 2014 20:51:37 +0200 (CEST) Received: from [172.30.42.85] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5C0A27C4031 for ; Sun, 12 Oct 2014 20:51:37 +0200 (CEST) Message-ID: <543ACDB7.5000300@alvestrand.no> Date: Sun, 12 Oct 2014 20:51:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OYCispnuvoXW6etQwLX2QMxie7E Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 18:51:43 -0000 On 08/21/2014 09:36 PM, Martin Thomson wrote: > On 21 August 2014 11:25, Roman Shpount wrote: >> All entities receive peer transport information from elsewhere, including >> gateways running ICE-Lite. Does it mean all of them need to perform consent? > That's the logical conclusion, yes. Careful with the words here. Every browser that sends data/media needs to verify that the reciever desires to continue to receive it. That means that it needs to initiate STUN binding requests for consent verification. Every entity, everywhere, needs to respond to those binding requests. I'm not sure which of those roles the words "perform consent" is meant to cover. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Sun Oct 12 12:50:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761801A873B for ; Sun, 12 Oct 2014 12:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6u5a0A1abFS for ; Sun, 12 Oct 2014 12:50:19 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883981A8730 for ; Sun, 12 Oct 2014 12:50:19 -0700 (PDT) Received: from [192.168.1.200] (p508F1AC6.dip0.t-ipconnect.de [80.143.26.198]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 36B721C1050E4; Sun, 12 Oct 2014 21:50:17 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <543ABE69.8030104@alvestrand.no> Date: Sun, 12 Oct 2014 21:50:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uXR5n2GFK_gYtPyrSzCw3QudkIo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 19:50:23 -0000 On 12 Oct 2014, at 19:46, Harald Alvestrand = wrote: > On 10/12/2014 06:50 PM, Michael Tuexen wrote: >> On 12 Oct 2014, at 17:28, Harald Alvestrand = wrote: >>=20 >>> On 10/12/2014 03:30 PM, Michael Tuexen wrote: >>>> On 12 Oct 2014, at 12:18, Harald Alvestrand = wrote: >>>>=20 >>>>> Given that the middle box has to: >>>>>=20 >>>>> - decrypt and encrypt all packets (because the keys are different) >>>>> - assert its own identity towards both endpoints (because = otherwise DTLS >>>>> doesn't work) >>>>> - be trusted by both endpoints (otherwise it's a MITM attack by = definition) >>>>> - manage SCTP congestion control independently on the two legs = (because >>>>> that's how SCTP works) >>>>>=20 >>>>> I don't see the reshuffling of packets between channel numbers to = be an >>>>> excessive *additional* burden. >>>> I agree CPU wise. But I have a question: Don't expect both = endpoints of a >>>> data channel to see the same "id" attribute? And isn't this = attribute >>>> the stream ID? So can conceptually a middlebox map the streams IDs? >>> The two ends don't see the same identity either, so the middle box = is not transparent. >> OK. So this means that the ID defined in=20 >> http://w3c.github.io/webrtc-pc/#widl-RTCDataChannel-id >> doesn't have to be the same on both ends, right? >=20 > It has to be the same on both ends of the SCTP connection. This means you can't remap the streams. Or am I missing something? Best regards Michael >=20 > It's just that (I think) you can't splice SCTP connections together; > either you terminate them, or you don't. >=20 > That's my understanding - YMMV. >=20 >> It would be useful >> to make that clear in the document. I always assumed that they are = the same >> on both ends... >>=20 >> Best regards >> Michael >>> The application has to know the middle box is there. So it has to be = written to deal with differing numbers at the two ends too. >>>=20 >>>=20 >>>=20 >=20 >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 >=20 From nobody Sun Oct 12 17:29:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB661A6F62 for ; Sun, 12 Oct 2014 17:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbrjNl1uvXJz for ; Sun, 12 Oct 2014 17:29:13 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D954A1A6EDA for ; Sun, 12 Oct 2014 17:29:13 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 313CA367C3A3E; Mon, 13 Oct 2014 00:29:10 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9D0TAf4000309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Oct 2014 20:29:12 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Sun, 12 Oct 2014 20:29:10 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Michael Tuexen , Harald Alvestrand Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CP1MhvaILuEckCrzly7+3a5apwp9uEAgAAW3wCAALT1AIAABaGAgAHozSGAAFJ8gIAAIqQAgAAIejA= Date: Mon, 13 Oct 2014 00:29:09 +0000 Message-ID: References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> In-Reply-To: <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DOEVRMR_rR82ncPAO9AKLtKFZig Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 00:29:15 -0000 > >> OK. So this means that the ID defined in > >> http://w3c.github.io/webrtc-pc/#widl-RTCDataChannel-id > >> doesn't have to be the same on both ends, right? > > > > It has to be the same on both ends of the SCTP connection. > This means you can't remap the streams. Or am I missing something? [Raju] When middle box is in the bearer path each end will see middle box a= s its peer. If the DCEP is used then it gets terminated at middle box and re-originated= towards=20 the other end after necessary stream id mapping. One way to avoid such mapping is to use external negotiation of stream ids = as=20 an alternative to inband DCEP. BR raju From nobody Mon Oct 13 02:51:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E841A8947; Mon, 13 Oct 2014 02:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXjEkgKjDhyE; Mon, 13 Oct 2014 02:51:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D621A893F; Mon, 13 Oct 2014 02:51:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013095115.8167.86416.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 02:51:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CaR8-OaDLc5GnHqOZrgUEwpo8N0 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 09:51:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Overview: Real Time Protocols for Browser-based Applications Author : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-12.txt Pages : 22 Date : 2014-10-13 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 13 10:03:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA7A1A1B2A for ; Mon, 13 Oct 2014 10:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai3qb-rTTp5C for ; Mon, 13 Oct 2014 10:03:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0633.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:633]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA301A1ACE for ; Mon, 13 Oct 2014 10:03:15 -0700 (PDT) Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1580.namprd05.prod.outlook.com (25.161.161.154) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Mon, 13 Oct 2014 17:02:52 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1049.012; Mon, 13 Oct 2014 17:02:52 +0000 From: "Wyss, Felix" To: "Makaraju, Maridi Raju (Raju)" , "Michael Tuexen" , Harald Alvestrand Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYIAADzmAgAAmfQCAAFWsAIAAG4cggAEmdgCAADW+gIAAINaAgAAXDgCAAA+BgIAAIqQAgABN64CAAPELcA== Date: Mon, 13 Oct 2014 17:02:52 +0000 Message-ID: <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [209.43.1.201] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1580; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(189002)(199003)(120916001)(92566001)(76576001)(106116001)(230783001)(101416001)(50986999)(54356999)(76176999)(4396001)(108616004)(93886004)(85306004)(74316001)(64706001)(20776003)(66066001)(106356001)(80022003)(46102003)(122556002)(105586002)(99286002)(86362001)(40100003)(95666004)(85852003)(2656002)(76482002)(21056001)(97736003)(33646002)(87936001)(31966008)(77096002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1580; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8p2diqSg5nxwcqcSwZ5qi6FM8Gc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 17:03:18 -0000 > > > It has to be the same on both ends of the SCTP connection. > > This means you can't remap the streams. Or am I missing something? > [Raju] When middle box is in the bearer path each end will see middle box > as its peer. > If the DCEP is used then it gets terminated at middle box and re- > originated towards the other end after necessary stream id mapping. > One way to avoid such mapping is to use external negotiation of stream id= s > as an alternative to inband DCEP. They would only see it as a peer if it were a full B2B user agent. As an e= xample, in VoIP the endpoints do not consider an SBC as a peer--yet it sits= in the middle and may inspect the media passing through it. =20 With respect to DCEP: If we already define a protocol for establishing the = channels in-band, why not make ID selection and conflict resolution an expl= icit part of it? That certainly would beat the IMHO rather distasteful DTL= S role hack. --Felix From nobody Mon Oct 13 10:58:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BD51A6FAB for ; Mon, 13 Oct 2014 10:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Log3ZxDBTJcO for ; Mon, 13 Oct 2014 10:58:24 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AAD1A6FD3 for ; Mon, 13 Oct 2014 10:58:13 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 826A9F381C7F7; Mon, 13 Oct 2014 17:58:10 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9DHwC5A003120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 13:58:12 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 13:58:12 -0400 From: "Makaraju, Maridi Raju (Raju)" To: "Wyss, Felix" , Michael Tuexen , Harald Alvestrand Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CP1MhvaILuEckCrzly7+3a5apwp9uEAgAAW3wCAALT1AIAABaGAgAHozSGAAFJ8gIAAIqQAgAAIejCAAVsVAP//xAPA Date: Mon, 13 Oct 2014 17:58:11 +0000 Message-ID: References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> In-Reply-To: <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/E7IR_1T94MykfeJm8F_GQ1Cee1Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 17:58:26 -0000 > They would only see it as a peer if it were a full B2B user agent. As an > example, in VoIP the endpoints do not consider an SBC as a peer--yet it s= its > in the middle and may inspect the media passing through it. I agree that from signaling point of view SBCs can be as transparent as pos= sible.=20 But from bearer point of view, in majority of the cases SBCs are not transp= arent and acts as a peer. Especially when services like NAP/T traversal, transcoding, encryption (DTL= S) are involved. >=20 > With respect to DCEP: If we already define a protocol for establishing th= e > channels in-band, why not make ID selection and conflict resolution an > explicit part of it? That certainly would beat the IMHO rather distastef= ul > DTLS role hack. Id selection is already part of the API. odd/even rule applies only when createDataChannel () API does not provide a= n id. An application can always override this by providing its own id allocation = scheme. e.g.: - Random id (2^16 unique ids). There is still a chance for glare. - In case of glare (upon SCTP stream reset) app can try to generate another= id. I am still not convinced of a middle box which terminates DTLS but neither maps stream ids nor uses external data channel negotiation. IMHO, it has to do either of those or clients need to have their own explicit management of= ids. So, I am not sure of complicating the DCEP to add conflict resolution is wo= rth it. BR Raju From nobody Mon Oct 13 12:28:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749781A8F33 for ; Mon, 13 Oct 2014 12:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7ZNqQiy0J5A for ; Mon, 13 Oct 2014 12:28:00 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A58C1A8FD6 for ; Mon, 13 Oct 2014 12:27:48 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hy10so6411626vcb.30 for ; Mon, 13 Oct 2014 12:27:47 -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:content-transfer-encoding; bh=6SdKpvd0tR+7IPVEYAIkthGTHP5IjoPvOBzwrw6FS8Q=; b=biBF2jHY202Nb/r6C1Fq2WDkyrcYza6odSpwt8NIBMMbfKM9ogb359r1jsUrBOctIt Xo79N5xzaIsJCcy6vr2widjikVrl4jUrw2D5YDexBf0HMtKdlJFUcy7SPSQw0HSmM1bf T29wrCmZL7XVZ9/DJYyQLHxkvLNdssrPEKgDhQ5YH7C34v+n8G1r0EJlCFrX3eDzpsWH SCpbJVrzWedFkpAv9lknY6bKS6X3z5ZhYnq5D0Co2Bi/X3y15q443ZEiRnGwuHd0/M1h Afv9jFAAilZKS77XewII28CN/+sT4gec5KfqpunR935RPpvdBmho50Gzr3mASE7wGiYa X3Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=6SdKpvd0tR+7IPVEYAIkthGTHP5IjoPvOBzwrw6FS8Q=; b=P1aXKHyYvA/bh9rWw9nyDLcKT+aZYJ7JWfMxWPPPikssEIjFKYwgs3v2C+7mMoWXI3 94XYYwHOPyleD6kPQaf5VMz8T02efS2MMSOydojsTJgZz+DF1exkHYExu2+U4lUy4XjI ovvfvFgm1WJgLfTn5hSweoUjth0ZwWTc8ID5RbvQ0N/QV+2Iy9gY3KMuqlmupOAZqh0c hj0zTqnjTsIkyq/NW+gSLsM0r1dH3r9xA35xRpsWNSn+Glt4AFUQiqm2Ib5IlysLCoIh YaDhWBoTa/njcyPIlDA6i0AtzmYPESufM1DwCQDKdnOML4ws5jMd1RVnGiQkz67JfYq6 Lfxg== X-Gm-Message-State: ALoCoQlKUp+mR+8MXmdaui3101uYX6PYNGA6aF9s3oPVMK2fP+58JptONOxU68GYCdaUT+FCa2Nh X-Received: by 10.52.74.233 with SMTP id x9mr683577vdv.38.1413228467354; Mon, 13 Oct 2014 12:27:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.173.136 with HTTP; Mon, 13 Oct 2014 12:27:06 -0700 (PDT) In-Reply-To: <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> From: Peter Thatcher Date: Mon, 13 Oct 2014 12:27:06 -0700 Message-ID: To: "Wyss, Felix" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IJkHmICR4KdDwi-t0qSDnbn5Cgk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 19:28:02 -0000 As pointed out by others mentioning "external negotiation", the application can use any mechanism it wants to choose the stream identifiers (SIDs). The even/odd choice is merely the default behavior there for the convenience of simple applications. More advanced applications, such as the kind you are describing with a middle box, can ignore the default even/odd behavior and choose the SIDs directly. On Fri, Oct 10, 2014 at 12:11 PM, Wyss, Felix wrote: > I'm sorry for being a bit late to the party, but I have a concern about s= ection 6.5 allowing use of the DTLS role for picking the SCTP stream identi= fiers (odd vs. even). It's an abstraction leak and complicates the implem= entation of middleboxes. The DTLS role is determined during the connection= establishment, so a middlebox that manages connections with two endpoints = to record the media passing through it can't guarantee that one side is the= DTLS server and the other the DTLS client because in its offers it is requ= ired to specify a=3Dsetup:actpass (see RFC#5763). That means it's at the m= ercy of the endpoint as to which DTLS role they pick. Worse, it is desirab= le for the answerers to pick 'active' as that can speed up the DTLS negotia= tion. > > I feel it would be better to explicitly require that applications are res= ponsible for identifier collision avoidance instead of allowing them to rel= y on the DTLS roles. > > Thanks, > --Felix Wyss > Interactive Intelligence, Inc. > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of The IESG >> Sent: Thursday, October 09, 2014 20:49 >> To: IETF-Announce >> Cc: rtcweb@ietf.org >> Subject: [rtcweb] Last Call: (We= bRTC >> Data Channels) to Proposed Standard >> >> >> The IESG has received a request from the Real-Time Communication in WEB- >> browsers WG (rtcweb) to consider the following document: >> - 'WebRTC Data Channels' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits fi= nal >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2014-10-23. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the beginni= ng of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> The WebRTC framework specifies protocol support for direct >> interactive rich communication using audio, video, and data between >> two peers' web-browsers. This document specifies the non-media data >> transport aspects of the WebRTC framework. It provides an >> architectural overview of how the Stream Control Transmission >> Protocol (SCTP) is used in the WebRTC context as a generic transport >> service allowing WEB-browsers to exchange generic data from peer to >> peer. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> _______________________________________________ >> 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 nobody Mon Oct 13 15:58:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64301A1A34 for ; Mon, 13 Oct 2014 15:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_WbzrSngzXA for ; Mon, 13 Oct 2014 15:58:10 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3FF1A1A2E for ; Mon, 13 Oct 2014 15:58:10 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id d1so8603075wiv.8 for ; Mon, 13 Oct 2014 15:58:09 -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=+Sz1bZk6mujQ+qdPmicQ8HFqEU5ndVCoPFdwmfmwphQ=; b=tdMzFs0Ux90dvWAzR0zR/IWjwykPcwoeTILLZBYaC1V1j4Z1lqzgQt42x1xtAFn55B vcq7SaBbQPTBdTFDEpA5QyAYsjoUJt2ceRfu2FKR2MGvVK2C6v0/Lo9Za44eRXG3CEZN 3sG9j7Dit+XFEp+bwXKOd8S9obfE1qS6yCw9r1ZHPhcu1jPs/NQ3dwxNEQEF1Dp1PQle 3d0DH7mB0NaSlvej/no1oEK3I7taU/f3ndOjuhX6nQn5CH4UgGU92/atpb7bofP2bKI5 fnjXBjdxLJr70dc067JI2hS9THkSLdx+D9OMpAyodq78VhJxmlENQ59fUADGbM1bXbvq 5RBg== X-Received: by 10.194.172.234 with SMTP id bf10mr1133826wjc.81.1413241088947; Mon, 13 Oct 2014 15:58:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.134.196 with HTTP; Mon, 13 Oct 2014 15:57:48 -0700 (PDT) From: Bernard Aboba Date: Mon, 13 Oct 2014 15:57:48 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6c2416bca3050555d553 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Cubw00xUBCqlHYPTwXmKU9fMUpk Subject: [rtcweb] Comments on draft-ietf-rtcweb-video Section 4.2 (H.264) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 22:58:12 -0000 --089e013c6c2416bca3050555d553 Content-Type: text/plain; charset=UTF-8 This section needs more work. Aside from requiring support for packetization mode 1, we could use additional text on robustness. Could aspects of existing H.264 robustness recommendations (such 3GPP S4-140961, designed for Video over LTE) could be incorporated? S4-140961 CR 26.114-0287 rev 1 Video telephony robustness improvements (Release 12) Qualcomm Incorporated, Ericsson 10, 11 agreed 15.4 --089e013c6c2416bca3050555d553 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This section needs more work.=C2=A0 Aside from requir= ing support for packetization mode 1, we could use additional text on robus= tness.=C2=A0

Could aspects of existing H.264=C2= =A0robustness=C2=A0recommendations (such 3GPP S4-140961, designed for Video= over LTE) could be incorporated?=C2=A0 =C2=A0

S4-140961

CR 26.114-0287 rev 1 Video telephony robustness improvements (Release 12)

Qualcomm Incorporated, Ericsson

= 10, 11

=C2=A0

agreed

15.4

--089e013c6c2416bca3050555d553-- From nobody Mon Oct 13 23:39:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6270A1A1A40 for ; Mon, 13 Oct 2014 23:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pofqGKUVqnck for ; Mon, 13 Oct 2014 23:39:48 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E1C1A6FAC for ; Mon, 13 Oct 2014 23:39:47 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-24-543cc531bf56 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.87.24955.135CC345; Tue, 14 Oct 2014 08:39:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 08:39:44 +0200 From: Christer Holmberg To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: Consent Freshness: Connection liveness/heartbeats Thread-Index: Ac/khDonWu2om5LnTYiCouL4O3PwFQC9Nuyg Date: Tue, 14 Oct 2014 06:39:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47B520@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D474980@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D474980@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D47B520ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja7hUZsQg+3HpC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrXzL9kLpiVVrJ/3h7WB8X1YFyMnh4SAiUTbk7PsELaYxIV7 69m6GLk4hASOMkqcbL0B5SxhlHjy9y1LFyMHB5uAhUT3P22QBhGBWIkVm6ezgNjCAnYSl9e8 Z4SI20vcmtjABGEbSUxpv80GYrMIqEp8uH+LGcTmFfCVODz3DVivEJB9e8IDMJtTwE/i+YNj YAcxAh30/dQasDnMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWwlibWHt4OdySyQL7FhgR7E KkGJkzOfsExgFJmFZNIshKpZSKogSnQkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanF SbnpRsZ6qUWZycXF+Xl6eaklmxiB8XNwy2/VHYyX3zgeYhTgYFTi4V3QbBMixJpYVlyZe4hR moNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYEy/fYFw3o9aA7fXFlV0i7f8d SlznNbuWyET72vdZP/1g8OT971of44Xqj75Oe7v9ddHO7zc5lZZ8enPxx92lGxedtVglH7PR 7MI17vfijwsmLq1bUa61JdGlzeXaHOUP18Kjdplk1K2aU73j94XW7Gcmy4N6o9yMmzf7M2el VR5qnrLn4s0HekosxRmJhlrMRcWJAI5B0ZCAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/L4ekZArCiOJFsDUHkEpLqxl9wMk Subject: Re: [rtcweb] Consent Freshness: Connection liveness/heartbeats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 06:39:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D47B520ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I suggest that we REMOVE the liveness/heartbeats feature from the consent r= efresh draft. As I said earlier, I see no need for sending additional conse= nt requests in addition to those already sent every 5th second. Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 10 October 2014 15:23 To: rtcweb@ietf.org Subject: [rtcweb] Consent Freshness: Connection liveness/heartbeats Hi, I have some questions on the connection liveness/heartbeat section of the d= raft. Q1: =3D=3D=3D The text says: "Similarly, if packets haven't been received within a certain perio= d, an application can request a consent check (heartbeat) be generated= ." BUT, if an endpoint is anyway sending consent requests every 5th second, wh= y aren't the those enough as hearbeats? As long as the endpoint receives re= sponses, it knows the remote endpoint is alive (the text even says that an = endpoint is considered alive as long as some data is received from it). And, if the endpoint does NOT receive responses to the consent requests, co= nsent will expire anyway. I DO understand that an ICE lite may want to send a heartbeat request if it= does not receive any data, as it doesn't send consent requests. Q2: =3D=3D=3D The text says: "Sending consent checks (heartbeats) at a high rate could allow a malicious application to generate congestion, so applications MUST NOT be able to send heartbeats at an average rate of more than 1 pe= r second." I don't think applications should be alowed to generate heartbeats this oft= en, and I see no need for it. Q3: =3D=3D=3D The spec is unclear on what happens is a response to a heartbeat request is= not received. I guess that is an application decision, but I think the spe= c should be clear that it does NOT have any impact on consent - the "real" = consent requests are used to determine. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D47B520ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I suggest that we REMOVE the liveness/heartbeats feature from the cons= ent refresh draft. As I said earlier, I see no need for sending additional = consent requests in addition to those already sent every 5th second.

 

Regards,

 

Christer

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 10 October 2014 15:23
To: rtcweb@ietf.org
Subject: [rtcweb] Consent Freshness: Connection liveness/heartbeats<= o:p>

 

Hi,

 

I have some questions on the co= nnection liveness/heartbeat section of the draft.

 

 

Q1:

=3D=3D=3D

 

The text says:

 

        = “Similarly, if packets haven't been received within a certain period,=

        an ap= plication can request a consent check (heartbeat) be generated.”=

 

BUT, if an endpoint is anyway sending conse= nt requests every 5th second, why aren’t the those enough = as hearbeats? As long as the endpoint receives responses, it knows the remote endpoint is alive (the text even says that an endpoint= is considered alive as long as some data is received from it).

 

And, if the endpoint does NOT receive respo= nses to the consent requests, consent will expire anyway.=

 

I DO understand that an ICE lite may want t= o send a heartbeat request if it does not receive any data, as it doesnR= 17;t send consent requests.

 

 

Q2:

=3D=3D=3D

 

The text says:

 

        “=
;Sending consent checks (heartbeats) at a high rate could allow a
        malicious a=
pplication to generate congestion, so applications MUST

        NOT be able=
 to send heartbeats at an average rate of more than 1 per=



        second.R=
21;


 


I don’t think applications should be alowed=
 to generate heartbeats this often, and I see no need for it.


 


 


Q3:


=3D=3D=3D


 


The spec is unclear on what happens is a re=
sponse to a heartbeat request is not received. I guess that is an applicati=
on decision, but I think the spec should be clear
 that it does NOT have any impact on consent – the “real”=
 consent requests are used to determine.


 


 


Regards,


 


Christer
--_000_7594FB04B1934943A5C02806D1A2204B1D47B520ESESSMB209erics_-- From nobody Tue Oct 14 00:33:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6611A6FC6 for ; Tue, 14 Oct 2014 00:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C06qYdRdKgyZ for ; Tue, 14 Oct 2014 00:33:36 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id E0DFC1A6FC3 for ; Tue, 14 Oct 2014 00:33:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B2F517C41CC; Tue, 14 Oct 2014 09:33:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXbe7xUG22fh; Tue, 14 Oct 2014 09:33:33 +0200 (CEST) Received: from [172.30.42.116] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id C0A987C40B6; Tue, 14 Oct 2014 09:33:33 +0200 (CEST) Message-ID: <543CD1CD.3000001@alvestrand.no> Date: Tue, 14 Oct 2014 09:33:33 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Wyss, Felix" , "Makaraju, Maridi Raju (Raju)" , Michael Tuexen References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> In-Reply-To: <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uIcO4A6iVSmwoFz1pD21YQPO_9o Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 07:33:40 -0000 On 10/13/2014 07:02 PM, Wyss, Felix wrote: >>>> It has to be the same on both ends of the SCTP connection. >>> This means you can't remap the streams. Or am I missing something? >> [Raju] When middle box is in the bearer path each end will see middle box >> as its peer. >> If the DCEP is used then it gets terminated at middle box and re- >> originated towards the other end after necessary stream id mapping. >> One way to avoid such mapping is to use external negotiation of stream ids >> as an alternative to inband DCEP. > They would only see it as a peer if it were a full B2B user agent. As an example, in VoIP the endpoints do not consider an SBC as a peer--yet it sits in the middle and may inspect the media passing through it. > > With respect to DCEP: If we already define a protocol for establishing the channels in-band, why not make ID selection and conflict resolution an explicit part of it? That certainly would beat the IMHO rather distasteful DTLS role hack. When rethinking this, I've come to the conclusion that my original conclusion (that there couldn't possibly be a point in preserving channel numbers across a relay) was probably wrong. Please consider that withdrawn. I now see a tradeoff between allowing such non-mapping boxes (operating below the SCTP layer but above the DTLS layer in our model) and avoiding additional complexity (either extending DCEP with glare resolution - something it was designed to avoid needing - or requiring such boxes to not use actpass). I agree that the DTLS hack is ugly. But glare resolution is ugly too. > > --Felix > -- Surveillance is pervasive. Go Dark. From nobody Tue Oct 14 01:32:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375371A6FE2 for ; Tue, 14 Oct 2014 01:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKeAzIVQoq9F for ; Tue, 14 Oct 2014 01:32:42 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A161A6FF0 for ; Tue, 14 Oct 2014 01:32:35 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so10456592wgh.9 for ; Tue, 14 Oct 2014 01:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ehAKIs+z/pQ4phbpzCNjTYrW0P7R2INDi6js5ftEmjY=; b=Y8AZkNngSIxJIQxZWDglT1crn9QjRSptIF7sevyYn9d9Huag6cHFIxxos6FD3NX0Ml oSps33MideKtobGvxRDvgiF59+Dhk8nJx0bACynR9Im7Q53P1emrUtzB36GXOBfnW3MC x8bDf9e37Wc1ZRhYzvRIKXpBijUipMSO9m8wkPUolBilYOPDwcuIklQLEN4VVIjqun4M NuvJXaZLWjCjsBDIUU1yGE27hjLjzgKD3/QKViVk7ePs7ER99Q+M4YcqQCUKNNGXEXGv c2YDKsve7IAI9kxnmFiYYCsiVcfz10wokvCdt6Ol1updWfYb/UjDdzK5sxtqFIBPKpd0 lLbw== MIME-Version: 1.0 X-Received: by 10.180.91.114 with SMTP id cd18mr3817686wib.37.1413275554308; Tue, 14 Oct 2014 01:32:34 -0700 (PDT) Received: by 10.180.197.168 with HTTP; Tue, 14 Oct 2014 01:32:34 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47B520@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D474980@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47B520@ESESSMB209.ericsson.se> Date: Tue, 14 Oct 2014 14:02:34 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d043749ad62674e05055ddbbc Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q5FX3DEGqKtPJkvdcyhpwAWR8nE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent Freshness: Connection liveness/heartbeats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 08:32:45 -0000 --f46d043749ad62674e05055ddbbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here are my thoughts: - Liveness was originally included in the document as a value added feature; the same messages used for consent can be used to also determine liveness and notify the application so that is can take some action before consent expires. In a sense it is not liveness per se, rather an early warning to the application before the doomsday. - The application is free to choose its liveness interval (of course, choosing an interval greater than the consent period isn't really useful). If a valid STUN binding response corresponding to one of the STUN requests sent in that interval has not been received, the browser notifies the application. This doesn't require new STUN requests to be sent or a change to how often they are sent for consent (and hence doesn't impact consent in any way). I see two options that wouldn't delay this work further: 1. Retain this simple functionality and fix the text, if we think this is useful/sufficient for applications. 2. Remove liveness entirely from the document, if we need a full-fledged liveness functionality. There are different ways of determining liveness depending on the use case (RTCP, DTLS heartbeat, TCP keepalive etc), so we could spin off a new doc and start with the problem/requirements. Feedback from the WG would help (either way works for me, though). Muthu On Tue, Oct 14, 2014 at 12:09 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I suggest that we REMOVE the liveness/heartbeats feature from the consent > refresh draft. As I said earlier, I see no need for sending additional > consent requests in addition to those already sent every 5th second. > > > > Regards, > > > > Christer > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 10 October 2014 15:23 > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Consent Freshness: Connection liveness/heartbeats > > > > Hi, > > > > I have some questions on the connection liveness/heartbeat section of the > draft. > > > > > > Q1: > > =3D=3D=3D > > > > The text says: > > > > =E2=80=9CSimilarly, if packets haven't been received within a cer= tain > period, > > an application can request a consent check (heartbeat) be > generated.=E2=80=9D > > > > BUT, if an endpoint is anyway sending consent requests every 5th second, > why aren=E2=80=99t the those enough as hearbeats? As long as the endpoint= receives > responses, it knows the remote endpoint is alive (the text even says that > an endpoint is considered alive as long as some data is received from it)= . > > > > And, if the endpoint does NOT receive responses to the consent requests, > consent will expire anyway. > > > > I DO understand that an ICE lite may want to send a heartbeat request if > it does not receive any data, as it doesn=E2=80=99t send consent requests= . > > > > > > Q2: > > =3D=3D=3D > > > > The text says: > > > > =E2=80=9CSending consent checks (heartbeats) at a high rate could= allow a > > malicious application to generate congestion, so applications MUS= T > > NOT be able to send heartbeats at an average rate of more than 1 = per > > second.=E2=80=9D > > > > I don=E2=80=99t think applications should be alowed to generate heartbeat= s this often, and I see no need for it. > > > > > > Q3: > > =3D=3D=3D > > > > The spec is unclear on what happens is a response to a heartbeat request > is not received. I guess that is an application decision, but I think the > spec should be clear that it does NOT have any impact on consent =E2=80= =93 the > =E2=80=9Creal=E2=80=9D consent requests are used to determine. > > > > > > Regards, > > > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d043749ad62674e05055ddbbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are my thoughts:
- Liveness was originally included in= the document as a value added feature; the same messages used for consent = can be used to also determine liveness and notify the application so that i= s can take some action before consent expires. In a sense it is not livenes= s per se, rather an early warning to the application before the doomsday.
- The application is free to choose its li= veness interval (of course, choosing an interval greater than the consent p= eriod isn't really useful). If a valid STUN binding response correspond= ing to one of the STUN requests sent in that interval has not been received= , the browser notifies the application. This doesn't require new STUN r= equests to be sent or a change to how often they are sent for consent (and = hence doesn't impact consent in any way).

I see two options that wouldn&#= 39;t delay this work further:
1. Retain t= his simple functionality and fix the text, if we think this is useful/suffi= cient for applications.
2. Remove livenes= s entirely from the document, if we need a full-fledged liveness functional= ity. There are different ways of determining liveness depending on the use = case (RTCP, DTLS heartbeat, TCP keepalive etc), so we could spin off a new = doc and start with the problem/requirements.

Feedback from the WG would help = (either way works for me, though).

Muthu

On Tue, Oct 14, 2014 at 12:09 PM, Christer= Holmberg <christer.holmberg@ericsson.com> wrot= e:

Hi,

=C2=A0

I suggest that = we REMOVE the liveness/heartbeats feature from the consent refresh draft. A= s I said earlier, I see no need for sending additional consent requests in = addition to those already sent every 5th second.

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 10 October 2014 15:23
To: rtcweb@ietf= .org
Subject: [rtcweb] Consent Freshness: Connection liveness/heartbeats<= u>

=C2=A0

Hi,

=C2=A0

I have some questions on the co= nnection liveness/heartbeat section of the draft.

=C2=A0

=C2=A0

Q1:

=3D=3D=3D<= /p>

=C2=A0

The text says:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2= =80=9CSimilarly, if packets haven't been received within a certain peri= od,

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 an applic= ation can request a consent check (heartbeat) be generated.=E2=80=9D=

=C2=A0

BUT, if an endpoint is anyway sending consent r= equests every 5th second, why aren=E2=80=99t the those enough as= hearbeats? As long as the endpoint receives responses, it knows the remote endpoint is alive (the text even says that an endpoint= is considered alive as long as some data is received from it).

=C2=A0

And, if the endpoint does NOT receive responses= to the consent requests, consent will expire anyway.<= /p>

=C2=A0

I DO understand that an ICE lite may want to se= nd a heartbeat request if it does not receive any data, as it doesn=E2=80= =99t send consent requests.

=C2=A0

=C2=A0

Q2:

=3D=3D=3D

=C2=A0

The text says:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=
=9CSending consent checks (heartbeats) at a high rate could allow a<=
u>
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 malicious a=
pplication to generate congestion, so applications MUST
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 NOT be able=
 to send heartbeats at an average rate of more than 1 per
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 second.=E2=
=80=9D
=C2=A0
I don=E2=80=99t think applications should be alow=
ed to generate heartbeats this often, and I see no need for it.

=C2=A0

=C2=A0

Q3:

=3D=3D=3D

=C2=A0

The spec is unclear on what happens is a respon= se to a heartbeat request is not received. I guess that is an application d= ecision, but I think the spec should be clear that it does NOT have any impact on consent =E2=80=93 the =E2=80=9Creal=E2= =80=9D consent requests are used to determine.

=C2=A0

=C2=A0

Regards,

=C2=A0

Christer


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


--f46d043749ad62674e05055ddbbc-- From nobody Tue Oct 14 01:34:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB65E1A0125 for ; Tue, 14 Oct 2014 01:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WWgEejCiuib for ; Tue, 14 Oct 2014 01:34:12 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCD61A00E8 for ; Tue, 14 Oct 2014 01:34:10 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-fd-543ce0004a0d Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CF.8C.24955.000EC345; Tue, 14 Oct 2014 10:34:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 10:34:08 +0200 From: Christer Holmberg To: Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] Consent Freshness: Connection liveness/heartbeats Thread-Index: Ac/khDonWu2om5LnTYiCouL4O3PwFQC9Nuyg////GwD//95FoA== Date: Tue, 14 Oct 2014 08:34:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47B97B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D474980@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47B520@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D47B97BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RpfxgU2IwaUfwhZ/NvtZrP3Xzu7A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZbz4/5+14Mp7xooZVw4zNzCuecnYxcjBISFg IrHxaHYXIyeQKSZx4d56NhBbSOAoo8T/jUpdjFxA9hJGiXnP5zGB1LMJWEh0/9MGqRERMJbY 0vKLFcRmFlCXuLP4HDuILSzgLvGpdycbSLmIgIfEjfmOEOVOEvMnLmQCsVkEVCWm33jPCGLz CvhK3P60gxVi1Q1Gief/14EVcQoEShxt2sIMYjMC3fb91BomiF3iEreezGeCuFlAYsme88wQ tqjEy8f/WCFsJYkfGy6xQNTnS5x6uYUJYpmgxMmZT1gmMIrOQjJqFpKyWUjKZgG9wCygKbF+ lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgTG2sEt v1V3MF5+43iIUYCDUYmHd0GzTYgQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamDsdp1xPPWfZf2+7LiXd6yutfjKv3i294yGis17n5+vyj6lHrmx0F4m/ulB 8TNpHAGx/3R4o3Lu3p8XvDP2XsCBOVFnvwlcaG1ge+j97/VRu9v8DczJz5S/3b5x/cHsn99l cvYFBq7eZSAT+UUz5+TPs2Gv9Dd/zcp8snVTf5hF2/Sr8c/bnysbKbEUZyQaajEXFScCAGqH lZiWAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0HFdU-f3wTacQHN8jceOWngIu_w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent Freshness: Connection liveness/heartbeats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 08:34:14 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D47B97BESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIG9wdGlvbiAyIDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IE11dGh1 IEFydWwgTW96aGkgUGVydW1hbCBbbWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tXQ0KU2VudDog MTQuIGxva2FrdXV0YSAyMDE0IDExOjMzDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBydGN3 ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDb25zZW50IEZyZXNobmVzczogQ29u bmVjdGlvbiBsaXZlbmVzcy9oZWFydGJlYXRzDQoNCkhlcmUgYXJlIG15IHRob3VnaHRzOg0KLSBM aXZlbmVzcyB3YXMgb3JpZ2luYWxseSBpbmNsdWRlZCBpbiB0aGUgZG9jdW1lbnQgYXMgYSB2YWx1 ZSBhZGRlZCBmZWF0dXJlOyB0aGUgc2FtZSBtZXNzYWdlcyB1c2VkIGZvciBjb25zZW50IGNhbiBi ZSB1c2VkIHRvIGFsc28gZGV0ZXJtaW5lIGxpdmVuZXNzIGFuZCBub3RpZnkgdGhlIGFwcGxpY2F0 aW9uIHNvIHRoYXQgaXMgY2FuIHRha2Ugc29tZSBhY3Rpb24gYmVmb3JlIGNvbnNlbnQgZXhwaXJl cy4gSW4gYSBzZW5zZSBpdCBpcyBub3QgbGl2ZW5lc3MgcGVyIHNlLCByYXRoZXIgYW4gZWFybHkg d2FybmluZyB0byB0aGUgYXBwbGljYXRpb24gYmVmb3JlIHRoZSBkb29tc2RheS4NCi0gVGhlIGFw cGxpY2F0aW9uIGlzIGZyZWUgdG8gY2hvb3NlIGl0cyBsaXZlbmVzcyBpbnRlcnZhbCAob2YgY291 cnNlLCBjaG9vc2luZyBhbiBpbnRlcnZhbCBncmVhdGVyIHRoYW4gdGhlIGNvbnNlbnQgcGVyaW9k IGlzbid0IHJlYWxseSB1c2VmdWwpLiBJZiBhIHZhbGlkIFNUVU4gYmluZGluZyByZXNwb25zZSBj b3JyZXNwb25kaW5nIHRvIG9uZSBvZiB0aGUgU1RVTiByZXF1ZXN0cyBzZW50IGluIHRoYXQgaW50 ZXJ2YWwgaGFzIG5vdCBiZWVuIHJlY2VpdmVkLCB0aGUgYnJvd3NlciBub3RpZmllcyB0aGUgYXBw bGljYXRpb24uIFRoaXMgZG9lc24ndCByZXF1aXJlIG5ldyBTVFVOIHJlcXVlc3RzIHRvIGJlIHNl bnQgb3IgYSBjaGFuZ2UgdG8gaG93IG9mdGVuIHRoZXkgYXJlIHNlbnQgZm9yIGNvbnNlbnQgKGFu ZCBoZW5jZSBkb2Vzbid0IGltcGFjdCBjb25zZW50IGluIGFueSB3YXkpLg0KDQpJIHNlZSB0d28g b3B0aW9ucyB0aGF0IHdvdWxkbid0IGRlbGF5IHRoaXMgd29yayBmdXJ0aGVyOg0KMS4gUmV0YWlu IHRoaXMgc2ltcGxlIGZ1bmN0aW9uYWxpdHkgYW5kIGZpeCB0aGUgdGV4dCwgaWYgd2UgdGhpbmsg dGhpcyBpcyB1c2VmdWwvc3VmZmljaWVudCBmb3IgYXBwbGljYXRpb25zLg0KMi4gUmVtb3ZlIGxp dmVuZXNzIGVudGlyZWx5IGZyb20gdGhlIGRvY3VtZW50LCBpZiB3ZSBuZWVkIGEgZnVsbC1mbGVk Z2VkIGxpdmVuZXNzIGZ1bmN0aW9uYWxpdHkuIFRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyBvZiBk ZXRlcm1pbmluZyBsaXZlbmVzcyBkZXBlbmRpbmcgb24gdGhlIHVzZSBjYXNlIChSVENQLCBEVExT IGhlYXJ0YmVhdCwgVENQIGtlZXBhbGl2ZSBldGMpLCBzbyB3ZSBjb3VsZCBzcGluIG9mZiBhIG5l dyBkb2MgYW5kIHN0YXJ0IHdpdGggdGhlIHByb2JsZW0vcmVxdWlyZW1lbnRzLg0KDQpGZWVkYmFj ayBmcm9tIHRoZSBXRyB3b3VsZCBoZWxwIChlaXRoZXIgd2F5IHdvcmtzIGZvciBtZSwgdGhvdWdo KS4NCg0KTXV0aHUNCg0KT24gVHVlLCBPY3QgMTQsIDIwMTQgYXQgMTI6MDkgUE0sIENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCkkgc3VnZ2VzdCB0aGF0IHdl IFJFTU9WRSB0aGUgbGl2ZW5lc3MvaGVhcnRiZWF0cyBmZWF0dXJlIGZyb20gdGhlIGNvbnNlbnQg cmVmcmVzaCBkcmFmdC4gQXMgSSBzYWlkIGVhcmxpZXIsIEkgc2VlIG5vIG5lZWQgZm9yIHNlbmRp bmcgYWRkaXRpb25hbCBjb25zZW50IHJlcXVlc3RzIGluIGFkZGl0aW9uIHRvIHRob3NlIGFscmVh ZHkgc2VudCBldmVyeSA1dGggc2Vjb25kLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9t OiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IDEw IE9jdG9iZXIgMjAxNCAxNToyMw0KVG86IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KU3ViamVjdDogW3J0Y3dlYl0gQ29uc2VudCBGcmVzaG5lc3M6IENvbm5lY3Rpb24g bGl2ZW5lc3MvaGVhcnRiZWF0cw0KDQpIaSwNCg0KSSBoYXZlIHNvbWUgcXVlc3Rpb25zIG9uIHRo ZSBjb25uZWN0aW9uIGxpdmVuZXNzL2hlYXJ0YmVhdCBzZWN0aW9uIG9mIHRoZSBkcmFmdC4NCg0K DQpRMToNCj09PQ0KDQpUaGUgdGV4dCBzYXlzOg0KDQogICAgICAgIOKAnFNpbWlsYXJseSwgaWYg cGFja2V0cyBoYXZlbid0IGJlZW4gcmVjZWl2ZWQgd2l0aGluIGEgY2VydGFpbiBwZXJpb2QsDQog ICAgICAgIGFuIGFwcGxpY2F0aW9uIGNhbiByZXF1ZXN0IGEgY29uc2VudCBjaGVjayAoaGVhcnRi ZWF0KSBiZSBnZW5lcmF0ZWQu4oCdDQoNCkJVVCwgaWYgYW4gZW5kcG9pbnQgaXMgYW55d2F5IHNl bmRpbmcgY29uc2VudCByZXF1ZXN0cyBldmVyeSA1dGggc2Vjb25kLCB3aHkgYXJlbuKAmXQgdGhl IHRob3NlIGVub3VnaCBhcyBoZWFyYmVhdHM/IEFzIGxvbmcgYXMgdGhlIGVuZHBvaW50IHJlY2Vp dmVzIHJlc3BvbnNlcywgaXQga25vd3MgdGhlIHJlbW90ZSBlbmRwb2ludCBpcyBhbGl2ZSAodGhl IHRleHQgZXZlbiBzYXlzIHRoYXQgYW4gZW5kcG9pbnQgaXMgY29uc2lkZXJlZCBhbGl2ZSBhcyBs b25nIGFzIHNvbWUgZGF0YSBpcyByZWNlaXZlZCBmcm9tIGl0KS4NCg0KQW5kLCBpZiB0aGUgZW5k cG9pbnQgZG9lcyBOT1QgcmVjZWl2ZSByZXNwb25zZXMgdG8gdGhlIGNvbnNlbnQgcmVxdWVzdHMs IGNvbnNlbnQgd2lsbCBleHBpcmUgYW55d2F5Lg0KDQpJIERPIHVuZGVyc3RhbmQgdGhhdCBhbiBJ Q0UgbGl0ZSBtYXkgd2FudCB0byBzZW5kIGEgaGVhcnRiZWF0IHJlcXVlc3QgaWYgaXQgZG9lcyBu b3QgcmVjZWl2ZSBhbnkgZGF0YSwgYXMgaXQgZG9lc27igJl0IHNlbmQgY29uc2VudCByZXF1ZXN0 cy4NCg0KDQpRMjoNCj09PQ0KDQpUaGUgdGV4dCBzYXlzOg0KDQoNCiAgICAgICAg4oCcU2VuZGlu ZyBjb25zZW50IGNoZWNrcyAoaGVhcnRiZWF0cykgYXQgYSBoaWdoIHJhdGUgY291bGQgYWxsb3cg YQ0KDQogICAgICAgIG1hbGljaW91cyBhcHBsaWNhdGlvbiB0byBnZW5lcmF0ZSBjb25nZXN0aW9u LCBzbyBhcHBsaWNhdGlvbnMgTVVTVA0KDQogICAgICAgIE5PVCBiZSBhYmxlIHRvIHNlbmQgaGVh cnRiZWF0cyBhdCBhbiBhdmVyYWdlIHJhdGUgb2YgbW9yZSB0aGFuIDEgcGVyDQoNCiAgICAgICAg c2Vjb25kLuKAnQ0KDQoNCg0KSSBkb27igJl0IHRoaW5rIGFwcGxpY2F0aW9ucyBzaG91bGQgYmUg YWxvd2VkIHRvIGdlbmVyYXRlIGhlYXJ0YmVhdHMgdGhpcyBvZnRlbiwgYW5kIEkgc2VlIG5vIG5l ZWQgZm9yIGl0Lg0KDQoNClEzOg0KPT09DQoNClRoZSBzcGVjIGlzIHVuY2xlYXIgb24gd2hhdCBo YXBwZW5zIGlzIGEgcmVzcG9uc2UgdG8gYSBoZWFydGJlYXQgcmVxdWVzdCBpcyBub3QgcmVjZWl2 ZWQuIEkgZ3Vlc3MgdGhhdCBpcyBhbiBhcHBsaWNhdGlvbiBkZWNpc2lvbiwgYnV0IEkgdGhpbmsg dGhlIHNwZWMgc2hvdWxkIGJlIGNsZWFyIHRoYXQgaXQgZG9lcyBOT1QgaGF2ZSBhbnkgaW1wYWN0 IG9uIGNvbnNlbnQg4oCTIHRoZSDigJxyZWFs4oCdIGNvbnNlbnQgcmVxdWVzdHMgYXJlIHVzZWQg dG8gZGV0ZXJtaW5lLg0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D47B97BESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+JiM0MzsxIGZvciBvcHRpb24gMiA6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNdXRo dSBBcnVsIE1vemhpIFBlcnVtYWwgW21haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiAxNC4gbG9rYWt1dXRhIDIwMTQgMTE6MzM8YnI+DQo8Yj5Ubzo8L2I+IENo cmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIENvbnNlbnQgRnJlc2huZXNzOiBDb25uZWN0aW9uIGxp dmVuZXNzL2hlYXJ0YmVhdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkhlcmUgYXJlIG15IHRob3VnaHRzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ LSBMaXZlbmVzcyB3YXMgb3JpZ2luYWxseSBpbmNsdWRlZCBpbiB0aGUgZG9jdW1lbnQgYXMgYSB2 YWx1ZSBhZGRlZCBmZWF0dXJlOyB0aGUgc2FtZSBtZXNzYWdlcyB1c2VkIGZvciBjb25zZW50IGNh biBiZSB1c2VkIHRvIGFsc28gZGV0ZXJtaW5lIGxpdmVuZXNzIGFuZCBub3RpZnkgdGhlIGFwcGxp Y2F0aW9uIHNvIHRoYXQgaXMNCiBjYW4gdGFrZSBzb21lIGFjdGlvbiBiZWZvcmUgY29uc2VudCBl eHBpcmVzLiBJbiBhIHNlbnNlIGl0IGlzIG5vdCBsaXZlbmVzcyBwZXIgc2UsIHJhdGhlciBhbiBl YXJseSB3YXJuaW5nIHRvIHRoZSBhcHBsaWNhdGlvbiBiZWZvcmUgdGhlIGRvb21zZGF5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4tIFRoZSBhcHBsaWNhdGlvbiBpcyBmcmVlIHRvIGNob29zZSBpdHMgbGl2ZW5lc3Mg aW50ZXJ2YWwgKG9mIGNvdXJzZSwgY2hvb3NpbmcgYW4gaW50ZXJ2YWwgZ3JlYXRlciB0aGFuIHRo ZSBjb25zZW50IHBlcmlvZCBpc24ndCByZWFsbHkgdXNlZnVsKS4gSWYgYSB2YWxpZCBTVFVOIGJp bmRpbmcgcmVzcG9uc2UgY29ycmVzcG9uZGluZw0KIHRvIG9uZSBvZiB0aGUgU1RVTiByZXF1ZXN0 cyBzZW50IGluIHRoYXQgaW50ZXJ2YWwgaGFzIG5vdCBiZWVuIHJlY2VpdmVkLCB0aGUgYnJvd3Nl ciBub3RpZmllcyB0aGUgYXBwbGljYXRpb24uIFRoaXMgZG9lc24ndCByZXF1aXJlIG5ldyBTVFVO IHJlcXVlc3RzIHRvIGJlIHNlbnQgb3IgYSBjaGFuZ2UgdG8gaG93IG9mdGVuIHRoZXkgYXJlIHNl bnQgZm9yIGNvbnNlbnQgKGFuZCBoZW5jZSBkb2Vzbid0IGltcGFjdCBjb25zZW50IGluIGFueSB3 YXkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBzZWUgdHdvIG9wdGlvbnMgdGhh dCB3b3VsZG4ndCBkZWxheSB0aGlzIHdvcmsgZnVydGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MS4gUmV0YWlu IHRoaXMgc2ltcGxlIGZ1bmN0aW9uYWxpdHkgYW5kIGZpeCB0aGUgdGV4dCwgaWYgd2UgdGhpbmsg dGhpcyBpcyB1c2VmdWwvc3VmZmljaWVudCBmb3IgYXBwbGljYXRpb25zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4y LiBSZW1vdmUgbGl2ZW5lc3MgZW50aXJlbHkgZnJvbSB0aGUgZG9jdW1lbnQsIGlmIHdlIG5lZWQg YSBmdWxsLWZsZWRnZWQgbGl2ZW5lc3MgZnVuY3Rpb25hbGl0eS4gVGhlcmUgYXJlIGRpZmZlcmVu dCB3YXlzIG9mIGRldGVybWluaW5nIGxpdmVuZXNzIGRlcGVuZGluZyBvbiB0aGUgdXNlIGNhc2Ug KFJUQ1AsIERUTFMgaGVhcnRiZWF0LA0KIFRDUCBrZWVwYWxpdmUgZXRjKSwgc28gd2UgY291bGQg c3BpbiBvZmYgYSBuZXcgZG9jIGFuZCBzdGFydCB3aXRoIHRoZSBwcm9ibGVtL3JlcXVpcmVtZW50 cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZlZWRiYWNrIGZyb20gdGhlIFdHIHdv dWxkIGhlbHAgKGVpdGhlciB3YXkgd29ya3MgZm9yIG1lLCB0aG91Z2gpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+TXV0aHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgT2N0IDE0LCAyMDE0IGF0IDEyOjA5 IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SGksPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SSBzdWdnZXN0IHRoYXQgd2UgUkVNT1ZFIHRoZSBsaXZlbmVzcy9oZWFydGJl YXRzIGZlYXR1cmUgZnJvbSB0aGUgY29uc2VudCByZWZyZXNoIGRyYWZ0LiBBcyBJIHNhaWQgZWFy bGllciwgSSBzZWUgbm8gbmVlZCBmb3Igc2VuZGluZyBhZGRpdGlvbmFsDQogY29uc2VudCByZXF1 ZXN0cyBpbiBhZGRpdGlvbiB0byB0aG9zZSBhbHJlYWR5IHNlbnQgZXZlcnkgNTxzdXA+dGg8L3N1 cD4gc2Vjb25kLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEg bmFtZT0iMTQ5MGQ2MjgxOTc0MWIxMF9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IHJ0Y3dlYiBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIg SG9sbWJlcmc8YnI+DQo8Yj5TZW50OjwvYj4gMTAgT2N0b2JlciAyMDE0IDE1OjIzPGJyPg0KPGI+ VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbcnRjd2ViXSBDb25zZW50 IEZyZXNobmVzczogQ29ubmVjdGlvbiBsaXZlbmVzcy9oZWFydGJlYXRzPHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRkkiPkhp LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg aGF2ZSBzb21lIHF1ZXN0aW9ucyBvbiB0aGUgY29ubmVjdGlvbiBsaXZlbmVzcy9oZWFydGJlYXQg c2VjdGlvbiBvZiB0aGUgZHJhZnQuPHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+UTE6PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PT09PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHRleHQgc2F5czo8 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnFNpbWlsYXJseSwgaWYgcGFja2V0cyBoYXZlbid0IGJlZW4g cmVjZWl2ZWQgd2l0aGluIGEgY2VydGFpbiBwZXJpb2QsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuIGFwcGxpY2F0aW9uIGNh biByZXF1ZXN0IGEgY29uc2VudCBjaGVjayAoaGVhcnRiZWF0KSBiZSBnZW5lcmF0ZWQu4oCdPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJV VCwgaWYgYW4gZW5kcG9pbnQgaXMgYW55d2F5IHNlbmRpbmcgY29uc2VudCByZXF1ZXN0cyBldmVy eSA1PHN1cD50aDwvc3VwPiBzZWNvbmQsIHdoeSBhcmVu4oCZdCB0aGUgdGhvc2UgZW5vdWdoIGFz IGhlYXJiZWF0cz8NCiBBcyBsb25nIGFzIHRoZSBlbmRwb2ludCByZWNlaXZlcyByZXNwb25zZXMs IGl0IGtub3dzIHRoZSByZW1vdGUgZW5kcG9pbnQgaXMgYWxpdmUgKHRoZSB0ZXh0IGV2ZW4gc2F5 cyB0aGF0IGFuIGVuZHBvaW50IGlzIGNvbnNpZGVyZWQgYWxpdmUgYXMgbG9uZyBhcyBzb21lIGRh dGEgaXMgcmVjZWl2ZWQgZnJvbSBpdCkuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QW5kLCBpZiB0aGUgZW5kcG9pbnQgZG9lcyBOT1Qg cmVjZWl2ZSByZXNwb25zZXMgdG8gdGhlIGNvbnNlbnQgcmVxdWVzdHMsIGNvbnNlbnQgd2lsbCBl eHBpcmUgYW55d2F5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5JIERPIHVuZGVyc3RhbmQgdGhhdCBhbiBJQ0UgbGl0ZSBtYXkgd2FudCB0 byBzZW5kIGEgaGVhcnRiZWF0IHJlcXVlc3QgaWYgaXQgZG9lcyBub3QgcmVjZWl2ZSBhbnkgZGF0 YSwgYXMgaXQgZG9lc27igJl0IHNlbmQNCiBjb25zZW50IHJlcXVlc3RzLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPlEyOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PT09PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSB0 ZXh0IHNheXM6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnFNlbmRpbmcgY29uc2VudCBjaGVja3MgKGhlYXJ0 YmVhdHMpIGF0IGEgaGlnaCByYXRlIGNvdWxkIGFsbG93IGE8c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbWFsaWNpb3VzIGFwcGxpY2F0aW9uIHRvIGdlbmVyYXRlIGNvbmdlc3Rpb24sIHNv IGFwcGxpY2F0aW9ucyBNVVNUPHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5PVCBiZSBh YmxlIHRvIHNlbmQgaGVhcnRiZWF0cyBhdCBhbiBhdmVyYWdlIHJhdGUgb2YgbW9yZSB0aGFuIDEg cGVyPHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlY29uZC7igJ08c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPiZuYnNwOzxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+SSBkb27igJl0IHRoaW5rIGFwcGxp Y2F0aW9ucyBzaG91bGQgYmUgYWxvd2VkIHRvIGdlbmVyYXRlIGhlYXJ0YmVhdHMgdGhpcyBvZnRl biwgYW5kIEkgc2VlIG5vIG5lZWQgZm9yIGl0LjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5R Mzo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPj09PTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgc3BlYyBpcyB1bmNsZWFyIG9uIHdo YXQgaGFwcGVucyBpcyBhIHJlc3BvbnNlIHRvIGEgaGVhcnRiZWF0IHJlcXVlc3QgaXMgbm90IHJl Y2VpdmVkLiBJIGd1ZXNzIHRoYXQgaXMgYW4gYXBwbGljYXRpb24NCiBkZWNpc2lvbiwgYnV0IEkg dGhpbmsgdGhlIHNwZWMgc2hvdWxkIGJlIGNsZWFyIHRoYXQgaXQgZG9lcyBOT1QgaGF2ZSBhbnkg aW1wYWN0IG9uIGNvbnNlbnQg4oCTIHRoZSDigJxyZWFs4oCdIGNvbnNlbnQgcmVxdWVzdHMgYXJl IHVzZWQgdG8gZGV0ZXJtaW5lLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJlZ2Fy ZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPkNocmlzdGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3 ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7594FB04B1934943A5C02806D1A2204B1D47B97BESESSMB209erics_-- From nobody Tue Oct 14 03:29:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2F71A7023 for ; Tue, 14 Oct 2014 03:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lelfpvslnnZM for ; Tue, 14 Oct 2014 03:29:03 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212241A7008 for ; Tue, 14 Oct 2014 03:29:03 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id EC19D1AFC13E3; Tue, 14 Oct 2014 10:29:00 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9EASxOS016974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 06:29:01 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 06:29:00 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "Muthu Arul Mozhi Perumal" Thread-Topic: [rtcweb] Consent Freshness: Connection liveness/heartbeats Thread-Index: Ac/khDonWu2om5LnTYiCouL4O3PwFQC9NuygAAx2CAAAAA3cgAAEujXQ Date: Tue, 14 Oct 2014 10:28:59 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D474980@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47B520@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47B97B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47B97B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5DE35AUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MMnIccPfodCweZvlDJplPg9FuYU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent Freshness: Connection liveness/heartbeats X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 10:29:05 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5DE35AUS70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoxLiBSZXRhaW4gdGhpcyBzaW1wbGUgZnVuY3Rpb25hbGl0eSBhbmQgZml4IHRoZSB0ZXh0LCBp ZiB3ZSB0aGluayB0aGlzIGlzIHVzZWZ1bC9zdWZmaWNpZW50IGZvciBhcHBsaWNhdGlvbnMuDQoy LiBSZW1vdmUgbGl2ZW5lc3MgZW50aXJlbHkgZnJvbSB0aGUgZG9jdW1lbnQsIGlmIHdlIG5lZWQg YSBmdWxsLWZsZWRnZWQgbGl2ZW5lc3MgZnVuY3Rpb25hbGl0eS4gVGhlcmUgYXJlIGRpZmZlcmVu dCB3YXlzIG9mIGRldGVybWluaW5nIGxpdmVuZXNzIGRlcGVuZGluZyBvbiB0aGUgdXNlIGNhc2Ug KFJUQ1AsIERUTFMgaGVhcnRiZWF0LCBUQ1Aga2VlcGFsaXZlIGV0YyksIHNvIHdlIGNvdWxkIHNw aW4gb2ZmIGEgbmV3IGRvYyBhbmQgc3RhcnQgd2l0aCB0aGUgcHJvYmxlbS9yZXF1aXJlbWVudHMu DQo8UmFqdT4NCkxpdmVsaW5lc3MgY2FuIGFuZCBoYXMgdG8gYmUgZGV0ZWN0ZWQgYXQgZWFjaCBs ZXZlbC4gRm9yIGUuZy4gbGFjayBvZiBSVENQIGNvdWxkIGJlIGNhdXNlZCBvZiBsYWNrIG9mIFNU VU4gbGl2ZWxpbmVzcyBvciBjcmFzaCBvZiBSVFAvUlRDUCBlbmRwb2ludDsgaXQgaXMgY3J1Y2lh bCB0byBrbm93IHRoZSBleGFjdCBjYXVzZSBmb3IgZGVidWdnaW5nIHB1cnBvc2UuDQpJIGFtIG9r IHdpdGggZWl0aGVyIG9wdGlvbiwgd2l0aCBhIHNsaWdodCBsZWFuIHRvd2FyZHMgYSBzZXBhcmF0 ZSBkcmFmdCwgYXMgbG9uZyBhcyBsaXZlbGluZXNzIGF0IGFsbCBsZXZlbHMgYXJlIGNhcHR1cmVk OyBlaXRoZXIgaW4gb25lIHNpbmdsZSBjb21iaW5lZCBkcmFmdCBvciBpbiByZXNwZWN0aXZlIGRy YWZ0cy4NCjwvUmFqdT4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E5DE35AUS70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLCJz ZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjEuIFJldGFpbiB0aGlzIHNpbXBsZSBmdW5jdGlvbmFsaXR5IGFuZCBmaXggdGhlIHRl eHQsIGlmIHdlIHRoaW5rIHRoaXMgaXMgdXNlZnVsL3N1ZmZpY2llbnQgZm9yIGFwcGxpY2F0aW9u cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Mi4gUmVtb3ZlIGxpdmVuZXNzIGVudGlyZWx5IGZyb20gdGhlIGRvY3VtZW50LCBpZiB3ZSBuZWVk IGEgZnVsbC1mbGVkZ2VkIGxpdmVuZXNzIGZ1bmN0aW9uYWxpdHkuIFRoZXJlIGFyZSBkaWZmZXJl bnQgd2F5cyBvZiBkZXRlcm1pbmluZyBsaXZlbmVzcyBkZXBlbmRpbmcgb24gdGhlIHVzZSBjYXNl IChSVENQLCBEVExTIGhlYXJ0YmVhdCwNCiBUQ1Aga2VlcGFsaXZlIGV0YyksIHNvIHdlIGNvdWxk IHNwaW4gb2ZmIGEgbmV3IGRvYyBhbmQgc3RhcnQgd2l0aCB0aGUgcHJvYmxlbS9yZXF1aXJlbWVu dHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtSYWp1Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5MaXZlbGluZXNzIGNhbiBhbmQgaGFzIHRvIGJlIGRldGVjdGVk IGF0IGVhY2ggbGV2ZWwuIEZvciBlLmcuIGxhY2sgb2YgUlRDUCBjb3VsZCBiZSBjYXVzZWQgb2Yg bGFjayBvZiBTVFVOIGxpdmVsaW5lc3Mgb3IgY3Jhc2ggb2YgUlRQL1JUQ1AgZW5kcG9pbnQ7IGl0 IGlzIGNydWNpYWwNCiB0byBrbm93IHRoZSBleGFjdCBjYXVzZSBmb3IgZGVidWdnaW5nIHB1cnBv c2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gb2sgd2l0aCBlaXRoZXIgb3B0 aW9uLCB3aXRoIGEgc2xpZ2h0IGxlYW4gdG93YXJkcyBhIHNlcGFyYXRlIGRyYWZ0LCBhcyBsb25n IGFzIGxpdmVsaW5lc3MgYXQgYWxsIGxldmVscyBhcmUgY2FwdHVyZWQ7IGVpdGhlciBpbiBvbmUg c2luZ2xlIGNvbWJpbmVkIGRyYWZ0DQogb3IgaW4gcmVzcGVjdGl2ZSBkcmFmdHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDsvUmFqdSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E5DE35AUS70UWXCHMBA02z_-- From nobody Tue Oct 14 10:39:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6561A90DE for ; Tue, 14 Oct 2014 10:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy_Qhu94nm1G for ; Tue, 14 Oct 2014 10:38:58 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF61C1A90DD for ; Tue, 14 Oct 2014 10:38:57 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9EHcsBx005904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Oct 2014 17:38:54 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9EHcs52030726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 19:38:54 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 19:38:54 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: ext Bernard Aboba , Christer Holmberg Thread-Topic: [rtcweb] Dates for rtcweb drafts Thread-Index: AQHP5HhSXVqbVYoTakSNp2wbJlZlVJwpZe2AgAAGiYCAAAQBAIAABycAgAZqz6A= Date: Tue, 14 Oct 2014 17:38:53 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8194BF99D@DEMUMBX005.nsn-intra.net> References: <9B317B02-CB28-40A3-9C7D-6D337682ADD6@iii.ca> <5437BA7C.6060402@alvestrand.no> <5438104B.7080008@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4750CA@ESESSMB209.ericsson.se> <866C6993-A4D0-4261-845C-DD420413453E@gmail.com> In-Reply-To: <866C6993-A4D0-4261-845C-DD420413453E@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1723 X-purgate-ID: 151667::1413308334-00001FC1-94C6FCF3/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0giH8-TYmbGoKm3yIaDXS0dfZ_g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Dates for rtcweb drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 17:39:00 -0000 +1 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Bernard > Aboba > Sent: Friday, October 10, 2014 7:39 PM > To: Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Dates for rtcweb drafts >=20 > +1. >=20 >=20 >=20 > > On Oct 10, 2014, at 10:13, Christer Holmberg > wrote: > > > > While you try to figure out who should ask the question, I'll give MY > answer: I think the draft should be adopted as a WG item :) > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand > > Sent: 10 October 2014 19:59 > > To: Martin Thomson > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Dates for rtcweb drafts > > > >> On 10/10/2014 06:35 PM, Martin Thomson wrote: > >>> On 10 October 2014 03:52, Harald Alvestrand > wrote: > >>> I'd like the chairs to indicate whether or not they are going to > >>> entertain -gateways for WG draft status too. > >> Maybe you should instead ask the working group. > > > > That's the question I think it's the WG chairs' job to ask. > > > > > > -- > > Surveillance is pervasive. Go Dark. > > > > _______________________________________________ > > 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 nobody Tue Oct 14 17:29:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA981A00CA for ; Tue, 14 Oct 2014 17:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNgmXOPyCtU8 for ; Tue, 14 Oct 2014 17:29:48 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.27]) by ietfa.amsl.com (Postfix) with ESMTP id 96C021A00BE for ; Tue, 14 Oct 2014 17:29:47 -0700 (PDT) Received: from userPC (unknown [122.167.224.12]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id D2ED33C0050; Wed, 15 Oct 2014 00:29:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1413332987; bh=rR7TAeE/lCAnx5ZjomXBwQ50cH6gdriQpi5nRjR2jyw=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OttYuI2tE7OegFOlJxe9BCGWZZA9OK6SnSwARG+dTqe9WtWMdzoBtIiVZzDoRUI/c evWAmKi4d3irOECdnxaiBkVCSyykJ78d/EXmQGG7Gz42+SBJCMp4oKzbysZy8WR/dt G9rpg/kxXA0SnA3WslVkH6INav9ubq5ArIu44pD0= From: "Parthasarathi R" To: "'Harald Alvestrand'" , "'Christer Holmberg'" , References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> <54363216.3060700@alvestrand.no> In-Reply-To: <54363216.3060700@alvestrand.no> Date: Wed, 15 Oct 2014 05:59:36 +0530 Message-ID: <010d01cfe80f$1c8e3930$55aaab90$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/jjnVOK+o8w9MwT86r1SubD5TE7wEgC5NQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020205.543DBFFB.00E7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4qFgmZVGyh-ZGySy0f4EccJZPkU Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 00:29:52 -0000 Hi Harald, >>> 2) It is not required to be endpoint but it shall be middle box. >> What do you mean by "middle box"? Again, that term is slippery. > I intent to say that the entity which is between two=20 > endpoints and it does not end any media session itself. Here, The=20 > confusion is that WebRTC compatible endpoint which is not an endpoint=20 > but it is a middle box. Seems that this entity (whatever it's called) isn't an endpoint at all, = so defining terms for endpoints shouldn't be relevant to whatever this = device is. There's always more boxes in the middle..... although as long as they = don't have the DTLS keys, it's limited what they can do to the packets. Could you please update the terminology as "WebRTC compatible device" = instead of WebRTC compatible endpoint as the entity is not required to = be endpoint. Thanks Partha. > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Thursday, October 09, 2014 12:29 PM > To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org > Subject: Re: [rtcweb] Definitions of WebRTC entities >=20 > On 10/08/2014 06:39 PM, Parthasarathi R wrote: > > Hi Harald, > > > > Please read inline. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: Harald Alvestrand [mailto:harald@alvestrand.no] > >> Sent: Tuesday, October 07, 2014 10:16 PM > >> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org > >> Subject: Re: [rtcweb] Definitions of WebRTC entities > >> > >> On 10/07/2014 06:21 PM, Parthasarathi R wrote: > >>> Hi Christer, > >>> > >>> I have no issue with WebRTC User Agent, WebRTC device, WebRTC > >> endpoint. > >>> I have bit trouble with WebRTC compatible endpoint as a entity = name > >> as > >>> 1) It may pass SRTP/data channel > >> What do you mean by "pass"? That's a slippery term. > > "relay" will be more appropriate term as mentioned in Sec 5 > Para 2 of draft-alvestrand-rtcweb-gateways. > > > >>> 2) It is not required to be endpoint but it shall be middle box. > >> What do you mean by "middle box"? Again, that term is slippery. > > I intent to say that the entity which is between two > endpoints and it does not end any media session itself. Here, The > confusion is that WebRTC compatible endpoint which is not an endpoint > but it is a middle box. >=20 > Seems that this entity (whatever it's called) isn't an endpoint at = all, > so defining terms for endpoints shouldn't be relevant to whatever this > device is. >=20 > There's always more boxes in the middle..... although as long as they > don't have the DTLS keys, it's limited what they can do to the = packets. >=20 >=20 >=20 > > > >>> WebRTC gateway looks more appropriate entity name in those > scenarios. > >> As written in my proposal, a WebRTC gateway is a WebRTC compatible > >> endpoint. > >> > > As per your proposal, we need to define WebRTC compatible > endpoint first which is super set of WebRTC gateway. Then, we need to > clarify which kind of WebRTC compatible endpoint qualify as WebRTC > gateway. But Christer wishes to have only two definition = (Full/Subset). > >=20 > And I don't agree with Christer, so then we're two :-) From nobody Tue Oct 14 21:34:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9F21A0250 for ; Tue, 14 Oct 2014 21:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kEv_1xeaRav for ; Tue, 14 Oct 2014 21:34:41 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE1A1A0217 for ; Tue, 14 Oct 2014 21:34:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 798E87C4226; Wed, 15 Oct 2014 06:34:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSYyi7BIW0Yd; Wed, 15 Oct 2014 06:34:38 +0200 (CEST) Received: from [172.30.42.116] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9CDFD7C328D; Wed, 15 Oct 2014 06:34:38 +0200 (CEST) Message-ID: <543DF95E.9060302@alvestrand.no> Date: Wed, 15 Oct 2014 06:34:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Parthasarathi R , 'Christer Holmberg' , rtcweb@ietf.org References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> <54363216.3060700@alvestrand.no> <010d01cfe80f$1c8e3930$55aaab90$@co.in> In-Reply-To: <010d01cfe80f$1c8e3930$55aaab90$@co.in> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mNa3krWiwSja5M_FZ7kLjl4jdZU Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 04:34:45 -0000 On 10/15/2014 02:29 AM, Parthasarathi R wrote: > Hi Harald, > > >>>> 2) It is not required to be endpoint but it shall be middle box. >>> What do you mean by "middle box"? Again, that term is slippery. >> I intent to say that the entity which is between two >> endpoints and it does not end any media session itself. Here, The >> confusion is that WebRTC compatible endpoint which is not an endpoint >> but it is a middle box. > Seems that this entity (whatever it's called) isn't an endpoint at all, so defining terms for endpoints shouldn't be relevant to whatever this device is. > > There's always more boxes in the middle..... although as long as they don't have the DTLS keys, it's limited what they can do to the packets. > > > Could you please update the terminology as "WebRTC compatible device" instead of WebRTC compatible endpoint as the entity is not required to be endpoint. No. I don't know what the device is, I don't know how to describe it, and I don't even know if I think it should exist. I will not define terminology for that. From nobody Tue Oct 14 21:54:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B730B1A026A for ; Tue, 14 Oct 2014 21:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_w2PaQTdsGY for ; Tue, 14 Oct 2014 21:54:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0611.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:611]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330941A0263 for ; Tue, 14 Oct 2014 21:54:55 -0700 (PDT) Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1580.namprd05.prod.outlook.com (25.161.161.154) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 15 Oct 2014 04:54:31 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1049.012; Wed, 15 Oct 2014 04:54:31 +0000 From: "Wyss, Felix" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYIAADzmAgAAmfQCAAFWsAIAAG4cggAEmdgCAADW+gIAAINaAgAAXDgCAAA+BgIAAIqQAgABN64CAAPELcIABF92AgAFR3BA= Date: Wed, 15 Oct 2014 04:54:31 +0000 Message-ID: <9648520ac90f4dbf8e2b5762ccce105b@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> <543CD1CD.3000001@alvestrand.no> In-Reply-To: <543CD1CD.3000001@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.147.12.61] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1580; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(189002)(199003)(51704005)(85852003)(86362001)(40100003)(95666004)(122556002)(105586002)(99286002)(97736003)(76482002)(21056001)(33646002)(87936001)(77096002)(31966008)(2656002)(54356999)(50986999)(2501002)(76176999)(108616004)(4396001)(230783001)(101416001)(76576001)(92566001)(120916001)(106116001)(106356001)(66066001)(99396003)(20776003)(80022003)(46102003)(64706001)(107886001)(107046002)(85306004)(74316001)(93886004)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1580; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: inin.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Felix.Wyss@inin.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/690wD_yPZCrtfzaw1O0vOktRJSQ Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 04:54:56 -0000 > When rethinking this, I've come to the conclusion that my original conclu= sion > (that there couldn't possibly be a point in preserving channel numbers ac= ross > a relay) was probably wrong. Please consider that withdrawn. Thank you! > I now see a tradeoff between allowing such non-mapping boxes (operating > below the SCTP layer but above the DTLS layer in our model) and avoiding > additional complexity (either extending DCEP with glare resolution - > something it was designed to avoid needing - or requiring such boxes to n= ot > use actpass). >=20 > I agree that the DTLS hack is ugly. But glare resolution is ugly too. Requiring middleboxes to assert a specific DTLS role instead of using actpa= ss as offerer conflicts with RFC#5763. That risks incompatibility with end= points that assume they get the choice as answerer and blindly use active--= or weren't tested by their vendor to be DTLS server as answerer and misbeha= ve in other ways. In our experience, interoperability is already challengi= ng enough with how vendors interpret RFCs liberally and appear to use a "su= nny weather" approach to test coverage. End customers won't take "big vend= or X doesn't implement an RFC correctly" as excuse why their system doesn't= work properly or won't interoperate. They paid a lot of money to have a w= orking solution--which then requires hacks and workarounds to make it work = somehow. Abstraction leaks and unexpected dependencies greatly increases t= he risk of incorrect implementations and bugs. =20 Speaking from an implementer's perspective, I thus strongly recommend again= st codification of conflicting requirements between RFCs and/or dubious dep= endencies across layers. =20 --Felix From nobody Wed Oct 15 01:47:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341221A044D for ; Wed, 15 Oct 2014 01:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ7_Kq70FrY9 for ; Wed, 15 Oct 2014 01:47:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F7E1A0125 for ; Wed, 15 Oct 2014 01:47:37 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9F8lWwM020304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Oct 2014 08:47:33 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9F8lRZn017723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 10:47:27 +0200 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 15 Oct 2014 10:47:27 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 10:47:26 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: ext Parthasarathi R , "'Harald Alvestrand'" , "'Christer Holmberg'" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Definitions of WebRTC entities Thread-Index: AQHP3t3hUWjlVh63kk6YNu/uIc2KBpweJDoAgAAM5gCAAE3fgIAAAswAgAY0V4CAAAcDgIABkGkAgADwDACACQFVAIAApGuA Date: Wed, 15 Oct 2014 08:47:26 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8194C0459@DEMUMBX005.nsn-intra.net> References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> <54363216.3060700@alvestrand.no> <010d01cfe80f$1c8e3930$55aaab90$@co.in> In-Reply-To: <010d01cfe80f$1c8e3930$55aaab90$@co.in> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5791 X-purgate-ID: 151667::1413362854-00001FC1-652A143A/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VFephKQTUAxb8-XCeF_p2TFVIA4 Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 08:47:41 -0000 Hi Harald, I wonder whether we can simplify the set of terms by removing "WebRTC endpo= int". What was the reason for introducing the term "WebRTC endpoint"? Wouldn't it= be enough to have "WebRTC UA", "WebRTC device" and "WebRTC-compatible devi= ce" (plus WebRTC gateway as special widespread case of compatible device)? A slight change in the chain of terms in -overview-12 could reduce the numb= er of definitions without losing meaning (I think): 1) A WebRTC User Agent (also called a WebRTC UA or a WebRTC browser) is som= ething that conforms to both the protocol specification and the Javascript = API defined above. A WebRTC User Agent conforms to both the protocol specif= ication and the Javascript API.=20 --> keep as is 2) A WebRTC device is something that conforms to the protocol specification= , but does not claim to implement the Javascript API.=20 --> replace "claim" by "have". This results in IS-A and we can pull out "WebRTC endpoint". (This is also better in line th= an the current chain with the statement in the draft "All WebRTC browsers (= UAs) are WebRTC devices, so any requirement on a WebRTC device also applies= to a WebRTC browser" 3) A WebRTC endpoint is either a WebRTC User Agent or a WebRTC device. --> delete 4) A WebRTC-compatible endpoint is an endpoint that is capable of successfu= lly communicating with a WebRTC endpoint, but may fail to meet some require= ments of a WebRTC endpoint. This may limit where in the network such an en= dpoint can be attached, or may limit the security guarantees that it offers= to others. --> replace "endpoint" by "device" 5) A WebRTC gateway is a WebRTC-compatible endpoint that mediates traffic t= o non-WebRTC entities. --> replace "endpoint" by "device" =A0 Kind regards, Uwe=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext > Parthasarathi R > Sent: Wednesday, October 15, 2014 2:30 AM > To: 'Harald Alvestrand'; 'Christer Holmberg'; rtcweb@ietf.org > Subject: Re: [rtcweb] Definitions of WebRTC entities >=20 > Hi Harald, >=20 > > >>> 2) It is not required to be endpoint but it shall be middle box. > >> What do you mean by "middle box"? Again, that term is slippery. > > I intent to say that the entity which is between two > > endpoints and it does not end any media session itself. Here, The > > confusion is that WebRTC compatible endpoint which is not an endpoint > > but it is a middle box. >=20 > Seems that this entity (whatever it's called) isn't an endpoint at all, > so defining terms for endpoints shouldn't be relevant to whatever this > device is. >=20 > There's always more boxes in the middle..... although as long as they > don't have the DTLS keys, it's limited what they can do to the packets. > >=20 > Could you please update the terminology as "WebRTC compatible device" > instead of WebRTC compatible endpoint as the entity is not required to > be endpoint. >=20 > Thanks > Partha. >=20 >=20 >=20 > > -----Original Message----- > > From: Harald Alvestrand [mailto:harald@alvestrand.no] > > Sent: Thursday, October 09, 2014 12:29 PM > > To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org > > Subject: Re: [rtcweb] Definitions of WebRTC entities > > > > On 10/08/2014 06:39 PM, Parthasarathi R wrote: > > > Hi Harald, > > > > > > Please read inline. > > > > > > Thanks > > > Partha > > > > > >> -----Original Message----- > > >> From: Harald Alvestrand [mailto:harald@alvestrand.no] > > >> Sent: Tuesday, October 07, 2014 10:16 PM > > >> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org > > >> Subject: Re: [rtcweb] Definitions of WebRTC entities > > >> > > >> On 10/07/2014 06:21 PM, Parthasarathi R wrote: > > >>> Hi Christer, > > >>> > > >>> I have no issue with WebRTC User Agent, WebRTC device, WebRTC > > >> endpoint. > > >>> I have bit trouble with WebRTC compatible endpoint as a entity > name > > >> as > > >>> 1) It may pass SRTP/data channel > > >> What do you mean by "pass"? That's a slippery term. > > > "relay" will be more appropriate term as mentioned in Sec > 5 > > Para 2 of draft-alvestrand-rtcweb-gateways. > > > > > >>> 2) It is not required to be endpoint but it shall be middle box. > > >> What do you mean by "middle box"? Again, that term is slippery. > > > I intent to say that the entity which is between two > > endpoints and it does not end any media session itself. Here, The > > confusion is that WebRTC compatible endpoint which is not an endpoint > > but it is a middle box. > > > > Seems that this entity (whatever it's called) isn't an endpoint at > all, > > so defining terms for endpoints shouldn't be relevant to whatever > this > > device is. > > > > There's always more boxes in the middle..... although as long as they > > don't have the DTLS keys, it's limited what they can do to the > packets. > > > > > > > > > > > >>> WebRTC gateway looks more appropriate entity name in those > > scenarios. > > >> As written in my proposal, a WebRTC gateway is a WebRTC compatible > > >> endpoint. > > >> > > > As per your proposal, we need to define WebRTC compatible > > endpoint first which is super set of WebRTC gateway. Then, we need to > > clarify which kind of WebRTC compatible endpoint qualify as WebRTC > > gateway. But Christer wishes to have only two definition > (Full/Subset). > > > > > > And I don't agree with Christer, so then we're two :-) >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Oct 15 02:39:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FA41A1A04 for ; Wed, 15 Oct 2014 02:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX9h31I0q6FC for ; Wed, 15 Oct 2014 02:39:55 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C67251A1A09 for ; Wed, 15 Oct 2014 02:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A2F6E7C4242; Wed, 15 Oct 2014 11:39:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUcIjzGdkzH0; Wed, 15 Oct 2014 11:39:52 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:fd69:746e:e861:9739]) by mork.alvestrand.no (Postfix) with ESMTPSA id 231557C4240; Wed, 15 Oct 2014 11:39:52 +0200 (CEST) Message-ID: <543E40E7.4030609@alvestrand.no> Date: Wed, 15 Oct 2014 11:39:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Rauschenbach, Uwe (NSN - DE/Munich)" , ext Parthasarathi R , 'Christer Holmberg' , "rtcweb@ietf.org" References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> <54363216.3060700@alvestrand.no> <010d01cfe80f$1c8e3930$55aaab90$@co.in> <56C2F665D49E0341B9DF5938005ACDF8194C0459@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF8194C0459@DEMUMBX005.nsn-intra.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d3-u8fFHhlOGVdrNK-vKPi0WTi4 Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 09:39:57 -0000 On 10/15/2014 10:47 AM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > Hi Harald, > > I wonder whether we can simplify the set of terms by removing "WebRTC endpoint". The reason for adding it was that it was already used in the RTCWEB RTP document, in harmony with the usage of "endpoint" in other RTP-releated specs. I'll take others' input on whether it's worth removing the term or keeping it. Note - from a strictly formalistic point of view, replacing all occurences of "WebRTC device" with "WebRTC endpoint" would have exactly the same effect. But the terms feel more comfortable to use in different contexts. > > What was the reason for introducing the term "WebRTC endpoint"? Wouldn't it be enough to have "WebRTC UA", "WebRTC device" and "WebRTC-compatible device" (plus WebRTC gateway as special widespread case of compatible device)? > > > A slight change in the chain of terms in -overview-12 could reduce the number of definitions without losing meaning (I think): > > > 1) A WebRTC User Agent (also called a WebRTC UA or a WebRTC browser) is something that conforms to both the protocol specification and the Javascript API defined above. A WebRTC User Agent conforms to both the protocol specification and the Javascript API. > --> keep as is > > 2) A WebRTC device is something that conforms to the protocol specification, but does not claim to implement the Javascript API. > --> replace "claim" by "have". This results in IS-A and we can pull out "WebRTC endpoint". (This is also better in line than the current chain with the statement in the draft "All WebRTC browsers (UAs) are WebRTC devices, so any requirement on a WebRTC device also applies to a WebRTC browser" > > 3) A WebRTC endpoint is either a WebRTC User Agent or a WebRTC device. > --> delete > > 4) A WebRTC-compatible endpoint is an endpoint that is capable of successfully communicating with a WebRTC endpoint, but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others. > --> replace "endpoint" by "device" > > 5) A WebRTC gateway is a WebRTC-compatible endpoint that mediates traffic to non-WebRTC entities. > --> replace "endpoint" by "device" > > Kind regards, > Uwe > > > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext >> Parthasarathi R >> Sent: Wednesday, October 15, 2014 2:30 AM >> To: 'Harald Alvestrand'; 'Christer Holmberg'; rtcweb@ietf.org >> Subject: Re: [rtcweb] Definitions of WebRTC entities >> >> Hi Harald, >> >> >>>>> 2) It is not required to be endpoint but it shall be middle box. >>>> What do you mean by "middle box"? Again, that term is slippery. >>> I intent to say that the entity which is between two >>> endpoints and it does not end any media session itself. Here, The >>> confusion is that WebRTC compatible endpoint which is not an endpoint >>> but it is a middle box. >> Seems that this entity (whatever it's called) isn't an endpoint at all, >> so defining terms for endpoints shouldn't be relevant to whatever this >> device is. >> >> There's always more boxes in the middle..... although as long as they >> don't have the DTLS keys, it's limited what they can do to the packets. >> >> >> Could you please update the terminology as "WebRTC compatible device" >> instead of WebRTC compatible endpoint as the entity is not required to >> be endpoint. >> >> Thanks >> Partha. >> >> >> >>> -----Original Message----- >>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>> Sent: Thursday, October 09, 2014 12:29 PM >>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org >>> Subject: Re: [rtcweb] Definitions of WebRTC entities >>> >>> On 10/08/2014 06:39 PM, Parthasarathi R wrote: >>>> Hi Harald, >>>> >>>> Please read inline. >>>> >>>> Thanks >>>> Partha >>>> >>>>> -----Original Message----- >>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>> Sent: Tuesday, October 07, 2014 10:16 PM >>>>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] Definitions of WebRTC entities >>>>> >>>>> On 10/07/2014 06:21 PM, Parthasarathi R wrote: >>>>>> Hi Christer, >>>>>> >>>>>> I have no issue with WebRTC User Agent, WebRTC device, WebRTC >>>>> endpoint. >>>>>> I have bit trouble with WebRTC compatible endpoint as a entity >> name >>>>> as >>>>>> 1) It may pass SRTP/data channel >>>>> What do you mean by "pass"? That's a slippery term. >>>> "relay" will be more appropriate term as mentioned in Sec >> 5 >>> Para 2 of draft-alvestrand-rtcweb-gateways. >>>>>> 2) It is not required to be endpoint but it shall be middle box. >>>>> What do you mean by "middle box"? Again, that term is slippery. >>>> I intent to say that the entity which is between two >>> endpoints and it does not end any media session itself. Here, The >>> confusion is that WebRTC compatible endpoint which is not an endpoint >>> but it is a middle box. >>> >>> Seems that this entity (whatever it's called) isn't an endpoint at >> all, >>> so defining terms for endpoints shouldn't be relevant to whatever >> this >>> device is. >>> >>> There's always more boxes in the middle..... although as long as they >>> don't have the DTLS keys, it's limited what they can do to the >> packets. >>> >>> >>>>>> WebRTC gateway looks more appropriate entity name in those >>> scenarios. >>>>> As written in my proposal, a WebRTC gateway is a WebRTC compatible >>>>> endpoint. >>>>> >>>> As per your proposal, we need to define WebRTC compatible >>> endpoint first which is super set of WebRTC gateway. Then, we need to >>> clarify which kind of WebRTC compatible endpoint qualify as WebRTC >>> gateway. But Christer wishes to have only two definition >> (Full/Subset). >>> >>> >>> And I don't agree with Christer, so then we're two :-) >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Oct 15 03:38:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241EC1A1AB8 for ; Wed, 15 Oct 2014 03:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIgk5whWm2P8 for ; Wed, 15 Oct 2014 03:38:17 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADFD1A1A9D for ; Wed, 15 Oct 2014 03:38:17 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 03F2A1FA1C436; Wed, 15 Oct 2014 10:38:14 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9FAcBlA032740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 12:38:14 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 12:38:11 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Harald Alvestrand , "Rauschenbach, Uwe (NSN - DE/Munich)" , ext Parthasarathi R , "'Christer Holmberg'" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Definitions of WebRTC entities Thread-Index: AQHP3t3f5D2VGYDPpkScrjp/MEhMKQEgC5NQnCfJqgCAAA6lgIAAL7/Q Date: Wed, 15 Oct 2014 10:38:10 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC3418E0@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> <54363216.3060700@alvestrand.no> <010d01cfe80f$1c8e3930$55aaab90$@co.in> <56C2F665D49E0341B9DF5938005ACDF8194C0459@DEMUMBX005.nsn-intra.net> <543E40E7.4030609@alvestrand.no> In-Reply-To: <543E40E7.4030609@alvestrand.no> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/U8uFz9Pa1GvEkF8pZbyoy7voFl0 Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 10:38:52 -0000 I'm also reluctant using "endpoint" as qualifier for WebRTC entities becaus= e in communication networks the notion of endpoint is fundamentally tight t= o a protocol (layer) (see e.g. (N)-connection-endpoint in ITU-T X.200). Now, "WebRTC" is not a single protocol, rather a suite of protocols in conc= ert. E.g., we got (DTLS)-connection-endpoints, (SCTP)-connection-endpoints, (UDP)-connection-endpoints, (RTP)-connection-endpoints, etc=20 within an WebRTC entity. Two cents from my side, of course you may always expand these OSI-ISO base = terms towards an (WebRTC)-endpoint (by highlighting the service access poin= t aspects and the "(WebRTC)-connection" concept). -Albrecht -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: Mittwoch, 15. Oktober 2014 11:40 To: Rauschenbach, Uwe (NSN - DE/Munich); ext Parthasarathi R; 'Christer Hol= mberg'; rtcweb@ietf.org Subject: Re: [rtcweb] Definitions of WebRTC entities On 10/15/2014 10:47 AM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > Hi Harald, > > I wonder whether we can simplify the set of terms by removing "WebRTC end= point". The reason for adding it was that it was already used in the RTCWEB RTP doc= ument, in harmony with the usage of "endpoint" in other RTP-releated specs. I'll take others' input on whether it's worth removing the term or keeping = it. Note - from a strictly formalistic point of view, replacing all occurences = of "WebRTC device" with "WebRTC endpoint" would have exactly the same effec= t. But the terms feel more comfortable to use in different contexts. > > What was the reason for introducing the term "WebRTC endpoint"? Wouldn't = it be enough to have "WebRTC UA", "WebRTC device" and "WebRTC-compatible de= vice" (plus WebRTC gateway as special widespread case of compatible device)= ? > > > A slight change in the chain of terms in -overview-12 could reduce the nu= mber of definitions without losing meaning (I think): > > > 1) A WebRTC User Agent (also called a WebRTC UA or a WebRTC browser) is s= omething that conforms to both the protocol specification and the Javascrip= t API defined above. A WebRTC User Agent conforms to both the protocol spec= ification and the Javascript API. > --> keep as is > > 2) A WebRTC device is something that conforms to the protocol specificati= on, but does not claim to implement the Javascript API. > --> replace "claim" by "have". This results in IS-A and we can pull out "WebRTC endpoint". (This is also better in line = than the current chain with the statement in the draft "All WebRTC browsers= (UAs) are WebRTC devices, so any requirement on a WebRTC device also appli= es to a WebRTC browser" > > 3) A WebRTC endpoint is either a WebRTC User Agent or a WebRTC device. > --> delete > > 4) A WebRTC-compatible endpoint is an endpoint that is capable of success= fully communicating with a WebRTC endpoint, but may fail to meet some requi= rements of a WebRTC endpoint. This may limit where in the network such an = endpoint can be attached, or may limit the security guarantees that it offe= rs to others. > --> replace "endpoint" by "device" > > 5) A WebRTC gateway is a WebRTC-compatible endpoint that mediates traffic= to non-WebRTC entities. > --> replace "endpoint" by "device" > =20 > Kind regards, > Uwe > > > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext=20 >> Parthasarathi R >> Sent: Wednesday, October 15, 2014 2:30 AM >> To: 'Harald Alvestrand'; 'Christer Holmberg'; rtcweb@ietf.org >> Subject: Re: [rtcweb] Definitions of WebRTC entities >> >> Hi Harald, >> >> >>>>> 2) It is not required to be endpoint but it shall be middle box. >>>> What do you mean by "middle box"? Again, that term is slippery. >>> I intent to say that the entity which is between two=20 >>> endpoints and it does not end any media session itself. Here, The=20 >>> confusion is that WebRTC compatible endpoint which is not an=20 >>> endpoint but it is a middle box. >> Seems that this entity (whatever it's called) isn't an endpoint at=20 >> all, so defining terms for endpoints shouldn't be relevant to=20 >> whatever this device is. >> >> There's always more boxes in the middle..... although as long as they=20 >> don't have the DTLS keys, it's limited what they can do to the packets. >> >> >> Could you please update the terminology as "WebRTC compatible device" >> instead of WebRTC compatible endpoint as the entity is not required=20 >> to be endpoint. >> >> Thanks >> Partha. >> >> >> >>> -----Original Message----- >>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>> Sent: Thursday, October 09, 2014 12:29 PM >>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org >>> Subject: Re: [rtcweb] Definitions of WebRTC entities >>> >>> On 10/08/2014 06:39 PM, Parthasarathi R wrote: >>>> Hi Harald, >>>> >>>> Please read inline. >>>> >>>> Thanks >>>> Partha >>>> >>>>> -----Original Message----- >>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>> Sent: Tuesday, October 07, 2014 10:16 PM >>>>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] Definitions of WebRTC entities >>>>> >>>>> On 10/07/2014 06:21 PM, Parthasarathi R wrote: >>>>>> Hi Christer, >>>>>> >>>>>> I have no issue with WebRTC User Agent, WebRTC device, WebRTC >>>>> endpoint. >>>>>> I have bit trouble with WebRTC compatible endpoint as a entity >> name >>>>> as >>>>>> 1) It may pass SRTP/data channel >>>>> What do you mean by "pass"? That's a slippery term. >>>> "relay" will be more appropriate term as mentioned in Sec >> 5 >>> Para 2 of draft-alvestrand-rtcweb-gateways. >>>>>> 2) It is not required to be endpoint but it shall be middle box. >>>>> What do you mean by "middle box"? Again, that term is slippery. >>>> I intent to say that the entity which is between two >>> endpoints and it does not end any media session itself. Here, The=20 >>> confusion is that WebRTC compatible endpoint which is not an=20 >>> endpoint but it is a middle box. >>> >>> Seems that this entity (whatever it's called) isn't an endpoint at >> all, >>> so defining terms for endpoints shouldn't be relevant to whatever >> this >>> device is. >>> >>> There's always more boxes in the middle..... although as long as=20 >>> they don't have the DTLS keys, it's limited what they can do to the >> packets. >>> >>> >>>>>> WebRTC gateway looks more appropriate entity name in those >>> scenarios. >>>>> As written in my proposal, a WebRTC gateway is a WebRTC compatible=20 >>>>> endpoint. >>>>> >>>> As per your proposal, we need to define WebRTC compatible >>> endpoint first which is super set of WebRTC gateway. Then, we need=20 >>> to clarify which kind of WebRTC compatible endpoint qualify as=20 >>> WebRTC gateway. But Christer wishes to have only two definition >> (Full/Subset). >>> >>> >>> And I don't agree with Christer, so then we're two :-) >> _______________________________________________ >> 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 nobody Wed Oct 15 07:21:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908731A7022 for ; Wed, 15 Oct 2014 07:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FqW_4qPgpvT for ; Wed, 15 Oct 2014 07:21:06 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855EE1A7009 for ; Wed, 15 Oct 2014 07:20:58 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id z12so1125881lbi.2 for ; Wed, 15 Oct 2014 07:20: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:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=PCcGz9l3Zq7OH4HanyMVHSLnEhuGP0FdBWGlT+QnXe4=; b=cFrYjgb0aW+5Chd5yKo0lJl49HYK4EJqHQXUJ418nrkIDBiADpGKVqOkdqG7vEP1hg 9Px0mnRd/R+Q1/i0yT3GeLkV7zzxpdp/HEIGWenAa0MtGurKI8pLPaLk2DP8SIKTphXY jaCuaqDlcSmk/jTWcUtwrZKaMaKr/IxZxVrWpohgeSLCb3wrIjjGPizFPdpJrcdgSy9b RL5NPR2CqwNpIVy/+EphvfAlMoRzUkZkIbZh53CuLIGw3zYHOw4O7/+wGWIrCO6WwOPh S4A5UMZtHPDcCir/nuN4OrBpEpCztXEDRYze/0rF5jAhWK5+Rt4pV92lkC5ygPvZGYZ6 7WOQ== MIME-Version: 1.0 X-Received: by 10.112.97.236 with SMTP id ed12mr12967338lbb.10.1413382856738; Wed, 15 Oct 2014 07:20:56 -0700 (PDT) Received: by 10.25.77.144 with HTTP; Wed, 15 Oct 2014 07:20:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Oct 2014 16:20:56 +0200 Message-ID: From: Victor Pascual Avila To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HnRBaG5k2WJNuN0RYHJfdhmgd6E Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 14:21:08 -0000 I surely missed a recent thread on it but, any plan to discuss MTI Video Codec in HI? I read in Jonathan's post it's part of the agenda? http://blogs.cisco.com/collaboration/ciscos-openh264-now-part-of-firefox/ Cheers, -Victor On Wed, Sep 11, 2013 at 7:51 PM, Victor Pascual Avila wrote: > Thanks for the feedback Ted! > > On Wed, Sep 11, 2013 at 7:48 PM, Ted Hardie wrote: >> Hi Victor, >> >> The chairs have been discussion the structure of the upcoming meeting, a= nd >> you should expect something from us soon. >> >> thanks, >> >> Ted >> >> >> On Tue, Sep 10, 2013 at 6:47 AM, Victor Pascual Avila >> wrote: >>> >>> Dear WG Chairs, >>> >>> What's the plan for the MTI video codec discussion? Are we planning to >>> discuss this during our next meeting? Is there a reason to delay this >>> decision? >>> >>> My apologies if this has already been discussed but could not find it >>> in the archives. >>> >>> Thanks, >>> -Victor >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > > -- > Victor Pascual =C3=81vila --=20 Victor Pascual =C3=81vila From nobody Wed Oct 15 09:56:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991B21A8A27 for ; Wed, 15 Oct 2014 09:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wa4zfZ0OieD for ; Wed, 15 Oct 2014 09:56:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004BA1A8A10 for ; Wed, 15 Oct 2014 09:56:06 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9FGu0Gm002551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Oct 2014 16:56:01 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9FGtvr2014530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 18:55:57 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 15 Oct 2014 18:55:57 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 18:55:57 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "ext Schwarz, Albrecht (Albrecht)" , Harald Alvestrand , ext Parthasarathi R , "'Christer Holmberg'" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Definitions of WebRTC entities Thread-Index: AQHP3t3hUWjlVh63kk6YNu/uIc2KBpweJDoAgAAM5gCAAE3fgIAAAswAgAY0V4CAAAcDgIABkGkAgADwDACACQFVAIAApGuA///1UoCAABBLAIAAUpHg Date: Wed, 15 Oct 2014 16:55:56 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8194C1087@DEMUMBX005.nsn-intra.net> References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> <54363216.3060700@alvestrand.no> <010d01cfe80f$1c8e3930$55aaab90$@co.in> <56C2F665D49E0341B9DF5938005ACDF8194C0459@DEMUMBX005.nsn-intra.net> <543E40E7.4030609@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC3418E0@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC3418E0@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 9382 X-purgate-ID: 151667::1413392161-0000437E-B7BE1F8B/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sp7PfBhMAl1hLb8YUT0OQdrR7sc Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 16:56:10 -0000 Hi Harald, all, I concur with Albrecht w.r.t. the meaning of "WebRTC endpoint". You mention= below that "endpoint" is included mainly because it is used in the rtp-usa= ge draft. But an "RTP endpoint" (a source and/or destination of RTP streams= ) may be different from a "WebRTC endpoint" (e.g. a mixing device). I believe that in the RTP usage draft, the meaning of "endpoint" is usually= "RTP endpoint" with the interpretation "RTP endpoint that supports WebRTC"= . Terms used as well are "WebRTC implementations of RTP endpoints" and "Web= RTC implementation". If we interpret "endpoint" that way, and maybe do some= editorial update of -rtp-usage replacing "WebRTC endpoint" with "WebRTC im= plementation" or "WebRTC-aware endpoint" (I can volunteer to write a propos= al), there will be no clash with the proposal to drop "WebRTC endpoint" fro= m -overview. The more neutral "device" for WebRTC entities allows to include entities th= at may not be the original source or final sink of RTP media streams. "Enti= ty" would be an alternative for "Device" but I seem to recall there was dis= like for that term previously.=20 Kind regards, Uwe=20 > -----Original Message----- > From: ext Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > Sent: Wednesday, October 15, 2014 12:38 PM > To: Harald Alvestrand; Rauschenbach, Uwe (NSN - DE/Munich); ext > Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org > Subject: RE: [rtcweb] Definitions of WebRTC entities >=20 > I'm also reluctant using "endpoint" as qualifier for WebRTC entities > because in communication networks the notion of endpoint is > fundamentally tight to a protocol (layer) (see e.g. (N)-connection- > endpoint in ITU-T X.200). > Now, "WebRTC" is not a single protocol, rather a suite of protocols in > concert. > E.g., we got > (DTLS)-connection-endpoints, > (SCTP)-connection-endpoints, > (UDP)-connection-endpoints, > (RTP)-connection-endpoints, > etc > within an WebRTC entity. >=20 > Two cents from my side, of course you may always expand these OSI-ISO > base terms towards an (WebRTC)-endpoint (by highlighting the service > access point aspects and the "(WebRTC)-connection" concept). >=20 > -Albrecht >=20 >=20 >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: Mittwoch, 15. Oktober 2014 11:40 > To: Rauschenbach, Uwe (NSN - DE/Munich); ext Parthasarathi R; 'Christer > Holmberg'; rtcweb@ietf.org > Subject: Re: [rtcweb] Definitions of WebRTC entities >=20 > On 10/15/2014 10:47 AM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > > Hi Harald, > > > > I wonder whether we can simplify the set of terms by removing "WebRTC > endpoint". >=20 > The reason for adding it was that it was already used in the RTCWEB RTP > document, in harmony with the usage of "endpoint" in other RTP-releated > specs. >=20 > I'll take others' input on whether it's worth removing the term or > keeping it. >=20 > Note - from a strictly formalistic point of view, replacing all > occurences of "WebRTC device" with "WebRTC endpoint" would have exactly > the same effect. But the terms feel more comfortable to use in > different contexts. >=20 > > > > What was the reason for introducing the term "WebRTC endpoint"? > Wouldn't it be enough to have "WebRTC UA", "WebRTC device" and "WebRTC- > compatible device" (plus WebRTC gateway as special widespread case of > compatible device)? > > > > > > A slight change in the chain of terms in -overview-12 could reduce > the number of definitions without losing meaning (I think): > > > > > > 1) A WebRTC User Agent (also called a WebRTC UA or a WebRTC browser) > is something that conforms to both the protocol specification and the > Javascript API defined above. A WebRTC User Agent conforms to both the > protocol specification and the Javascript API. > > --> keep as is > > > > 2) A WebRTC device is something that conforms to the protocol > specification, but does not claim to implement the Javascript API. > > --> replace "claim" by "have". This results in IS-A > and we can pull out "WebRTC endpoint". (This is also > better in line than the current chain with the statement in the draft > "All WebRTC browsers (UAs) are WebRTC devices, so any requirement on a > WebRTC device also applies to a WebRTC browser" > > > > 3) A WebRTC endpoint is either a WebRTC User Agent or a WebRTC > device. > > --> delete > > > > 4) A WebRTC-compatible endpoint is an endpoint that is capable of > successfully communicating with a WebRTC endpoint, but may fail to meet > some requirements of a WebRTC endpoint. This may limit where in the > network such an endpoint can be attached, or may limit the security > guarantees that it offers to others. > > --> replace "endpoint" by "device" > > > > 5) A WebRTC gateway is a WebRTC-compatible endpoint that mediates > traffic to non-WebRTC entities. > > --> replace "endpoint" by "device" > > > > Kind regards, > > Uwe > > > > > > > >> -----Original Message----- > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext > >> Parthasarathi R > >> Sent: Wednesday, October 15, 2014 2:30 AM > >> To: 'Harald Alvestrand'; 'Christer Holmberg'; rtcweb@ietf.org > >> Subject: Re: [rtcweb] Definitions of WebRTC entities > >> > >> Hi Harald, > >> > >> > >>>>> 2) It is not required to be endpoint but it shall be middle box. > >>>> What do you mean by "middle box"? Again, that term is slippery. > >>> I intent to say that the entity which is between two > >>> endpoints and it does not end any media session itself. Here, The > >>> confusion is that WebRTC compatible endpoint which is not an > >>> endpoint but it is a middle box. > >> Seems that this entity (whatever it's called) isn't an endpoint at > >> all, so defining terms for endpoints shouldn't be relevant to > >> whatever this device is. > >> > >> There's always more boxes in the middle..... although as long as > they > >> don't have the DTLS keys, it's limited what they can do to the > packets. > >> > >> > >> Could you please update the terminology as "WebRTC compatible > device" > >> instead of WebRTC compatible endpoint as the entity is not required > >> to be endpoint. > >> > >> Thanks > >> Partha. > >> > >> > >> > >>> -----Original Message----- > >>> From: Harald Alvestrand [mailto:harald@alvestrand.no] > >>> Sent: Thursday, October 09, 2014 12:29 PM > >>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org > >>> Subject: Re: [rtcweb] Definitions of WebRTC entities > >>> > >>> On 10/08/2014 06:39 PM, Parthasarathi R wrote: > >>>> Hi Harald, > >>>> > >>>> Please read inline. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>>> -----Original Message----- > >>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] > >>>>> Sent: Tuesday, October 07, 2014 10:16 PM > >>>>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org > >>>>> Subject: Re: [rtcweb] Definitions of WebRTC entities > >>>>> > >>>>> On 10/07/2014 06:21 PM, Parthasarathi R wrote: > >>>>>> Hi Christer, > >>>>>> > >>>>>> I have no issue with WebRTC User Agent, WebRTC device, WebRTC > >>>>> endpoint. > >>>>>> I have bit trouble with WebRTC compatible endpoint as a entity > >> name > >>>>> as > >>>>>> 1) It may pass SRTP/data channel > >>>>> What do you mean by "pass"? That's a slippery term. > >>>> "relay" will be more appropriate term as mentioned in Sec > >> 5 > >>> Para 2 of draft-alvestrand-rtcweb-gateways. > >>>>>> 2) It is not required to be endpoint but it shall be middle box. > >>>>> What do you mean by "middle box"? Again, that term is slippery. > >>>> I intent to say that the entity which is between two > >>> endpoints and it does not end any media session itself. Here, The > >>> confusion is that WebRTC compatible endpoint which is not an > >>> endpoint but it is a middle box. > >>> > >>> Seems that this entity (whatever it's called) isn't an endpoint at > >> all, > >>> so defining terms for endpoints shouldn't be relevant to whatever > >> this > >>> device is. > >>> > >>> There's always more boxes in the middle..... although as long as > >>> they don't have the DTLS keys, it's limited what they can do to the > >> packets. > >>> > >>> > >>>>>> WebRTC gateway looks more appropriate entity name in those > >>> scenarios. > >>>>> As written in my proposal, a WebRTC gateway is a WebRTC > compatible > >>>>> endpoint. > >>>>> > >>>> As per your proposal, we need to define WebRTC compatible > >>> endpoint first which is super set of WebRTC gateway. Then, we need > >>> to clarify which kind of WebRTC compatible endpoint qualify as > >>> WebRTC gateway. But Christer wishes to have only two definition > >> (Full/Subset). > >>> > >>> > >>> And I don't agree with Christer, so then we're two :-) > >> _______________________________________________ > >> 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 nobody Wed Oct 15 10:11:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A781A8AEC for ; Wed, 15 Oct 2014 10:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzyjm8hsSRsJ for ; Wed, 15 Oct 2014 10:11:19 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7519A1AC3B3 for ; Wed, 15 Oct 2014 10:10:06 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id rp18so1651815iec.41 for ; Wed, 15 Oct 2014 10:10:05 -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=cA0S41WOdmEfCiEg5XrxRI7kaOehPtKF45JoSrEP20M=; b=E9PbKzUhB9fNMZBYr/EUplrnCbrmGQ9DxShMTXLfrdmI46vZJIRR9PM6OQ+7VAbPAc TYzabTBb3fU8C0HdZwjOzxkybzY5YBCD7553W5LfiXETkzASHp9jrXULKz+IcJ6w+ciA Tjh2MQysfrDOSKx61T4PX+g7m4NSR1j0e/9mVdz2tKEEKldLBwzG2TkQX/FRHwIsJFcW 9Pa9th/HmK9bBDDs41Sdj9wgnQmjpJey+YjsInMyDtq7cIvShUY1z5tQ4wYf9MBH7QbB dt143E/Qup5fnzPvIhBpEd0qFEGONMnLaCO17q3zwFSVISLwZNoXPYInzvW1j7Z7RK6M S8qw== MIME-Version: 1.0 X-Received: by 10.107.31.202 with SMTP id f193mr11398758iof.16.1413393005788; Wed, 15 Oct 2014 10:10:05 -0700 (PDT) Received: by 10.43.3.4 with HTTP; Wed, 15 Oct 2014 10:10:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Oct 2014 10:10:05 -0700 Message-ID: From: Ted Hardie To: Victor Pascual Avila Content-Type: multipart/alternative; boundary=001a1140cac009c231050579340b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SSOKrovv1uNKKftIDInyvhkac9s Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 17:11:22 -0000 --001a1140cac009c231050579340b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Victor, As you may remember, we tabled discussion of video codecs back in January, and said that the topic could be re-opened 6 weeks prior to IETF 91. We do anticipate discussing it at this meeting, likely in the Thursday slot (since there is a related BoF earlier that day). regards, Ted Hardie On Wed, Oct 15, 2014 at 7:20 AM, Victor Pascual Avila < victor.pascual.avila@gmail.com> wrote: > I surely missed a recent thread on it but, any plan to discuss MTI > Video Codec in HI? > > I read in Jonathan's post it's part of the agenda? > http://blogs.cisco.com/collaboration/ciscos-openh264-now-part-of-firefox/ > > Cheers, > -Victor > > On Wed, Sep 11, 2013 at 7:51 PM, Victor Pascual Avila > wrote: > > Thanks for the feedback Ted! > > > > On Wed, Sep 11, 2013 at 7:48 PM, Ted Hardie wrote: > >> Hi Victor, > >> > >> The chairs have been discussion the structure of the upcoming meeting, > and > >> you should expect something from us soon. > >> > >> thanks, > >> > >> Ted > >> > >> > >> On Tue, Sep 10, 2013 at 6:47 AM, Victor Pascual Avila > >> wrote: > >>> > >>> Dear WG Chairs, > >>> > >>> What's the plan for the MTI video codec discussion? Are we planning t= o > >>> discuss this during our next meeting? Is there a reason to delay this > >>> decision? > >>> > >>> My apologies if this has already been discussed but could not find it > >>> in the archives. > >>> > >>> Thanks, > >>> -Victor > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >> > >> > > > > > > > > -- > > Victor Pascual =C3=81vila > > > > -- > Victor Pascual =C3=81vila > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1140cac009c231050579340b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Victor,

As you may rem= ember, we tabled discussion of video codecs back in January, and said that = the topic could be re-opened 6 weeks prior to IETF 91.=C2=A0 We do anticipa= te discussing it at this meeting, likely in the Thursday slot (since there = is a related BoF earlier that day).

regards,

= Ted Hardie

On Wed, Oct 15, 2014 at 7:20 AM, Victor Pascual Avila <victor.pascual.avila@gmail.com> wrote:
I surely missed a recent thread on it but, any plan to discu= ss MTI
Video Codec in HI?

I read in Jonathan's post it's part of the agenda?
http://blogs.cisco.com/collaboration/ciscos-op= enh264-now-part-of-firefox/

Cheers,
-Victor

On Wed, Sep 11, 2013 at 7:51 PM, Victor Pascual Avila
<victor.pascual.avila@gmail.com> wrote:
> Thanks for the feedback Ted!
>
> On Wed, Sep 11, 2013 at 7:48 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> Hi Victor,
>>
>> The chairs have been discussion the structure of the upcoming meet= ing, and
>> you should expect something from us soon.
>>
>> thanks,
>>
>> Ted
>>
>>
>> On Tue, Sep 10, 2013 at 6:47 AM, Victor Pascual Avila
>> <victor.pascu= al.avila@gmail.com> wrote:
>>>
>>> Dear WG Chairs,
>>>
>>> What's the plan for the MTI video codec discussion? Are we= planning to
>>> discuss this during our next meeting? Is there a reason to del= ay this
>>> decision?
>>>
>>> My apologies if this has already been discussed but could not = find it
>>> in the archives.
>>>
>>> Thanks,
>>> -Victor
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
>
> --
> Victor Pascual =C3=81vila



--
Victor Pascual =C3=81vila

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

--001a1140cac009c231050579340b-- From nobody Wed Oct 15 10:26:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8731A8AA8 for ; Wed, 15 Oct 2014 10:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSAHjIpANkti for ; Wed, 15 Oct 2014 10:26:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD6B1AC3CD for ; Wed, 15 Oct 2014 10:26:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5F6C47C424D; Wed, 15 Oct 2014 19:26:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu9mZtAotVHr; Wed, 15 Oct 2014 19:26:42 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:fd69:746e:e861:9739]) by mork.alvestrand.no (Postfix) with ESMTPSA id 60CF07C424B; Wed, 15 Oct 2014 19:26:42 +0200 (CEST) Message-ID: <543EAE51.1060508@alvestrand.no> Date: Wed, 15 Oct 2014 19:26:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Rauschenbach, Uwe (NSN - DE/Munich)" , "ext Schwarz, Albrecht (Albrecht)" , ext Parthasarathi R , 'Christer Holmberg' , "rtcweb@ietf.org" References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> <54363216.3060700@alvestrand.no> <010d01cfe80f$1c8e3930$55aaab90$@co.in> <56C2F665D49E0341B9DF5938005ACDF8194C0459@DEMUMBX005.nsn-intra.net> <543E40E7.4030609@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC3418E0@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF8194C1087@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF8194C1087@DEMUMBX005.nsn-intra.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/a6HFJDPFJx07KJPtjvhN5hZL_bA Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 17:26:50 -0000 On 10/15/2014 06:55 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > Hi Harald, all, > > I concur with Albrecht w.r.t. the meaning of "WebRTC endpoint". You mention below that "endpoint" is included mainly because it is used in the rtp-usage draft. But an "RTP endpoint" (a source and/or destination of RTP streams) may be different from a "WebRTC endpoint" (e.g. a mixing device). To be more precise: The term "WebRTC endpoint" is used in the rtp-usage draft. Three times. > > I believe that in the RTP usage draft, the meaning of "endpoint" is usually "RTP endpoint" with the interpretation "RTP endpoint that supports WebRTC". Terms used as well are "WebRTC implementations of RTP endpoints" and "WebRTC implementation". If we interpret "endpoint" that way, and maybe do some editorial update of -rtp-usage replacing "WebRTC endpoint" with "WebRTC implementation" or "WebRTC-aware endpoint" (I can volunteer to write a proposal), there will be no clash with the proposal to drop "WebRTC endpoint" from -overview. "WebRTC implementation" is defined nowhere, so I'm happy to have that term removed from service. > > The more neutral "device" for WebRTC entities allows to include entities that may not be the original source or final sink of RTP media streams. "Entity" would be an alternative for "Device" but I seem to recall there was dislike for that term previously. I would be happy to exclude devices that are participating in, but not terminating, an RTP session (such as RTP translators and other quasi-multicast devices) from consideration in this set of documents. I think we already have strong advice against them: "This limitation means that some of the RTP middlebox-based topologies are not suitable for use in the WebRTC environment. Specifically: o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, since they make the use of RTCP for congestion control and quality of service reports problematic (see Section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology SHOULD NOT be used because its safe use requires a congestion control algorithm or RTP circuit breaker that handles point to multipoint, which has not yet been standardised. " If we were to start talking about them, this is a topic of far more wide-ranging debate than mere terminology. > > Kind regards, > Uwe > > >> -----Original Message----- >> From: ext Schwarz, Albrecht (Albrecht) >> [mailto:albrecht.schwarz@alcatel-lucent.com] >> Sent: Wednesday, October 15, 2014 12:38 PM >> To: Harald Alvestrand; Rauschenbach, Uwe (NSN - DE/Munich); ext >> Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org >> Subject: RE: [rtcweb] Definitions of WebRTC entities >> >> I'm also reluctant using "endpoint" as qualifier for WebRTC entities >> because in communication networks the notion of endpoint is >> fundamentally tight to a protocol (layer) (see e.g. (N)-connection- >> endpoint in ITU-T X.200). >> Now, "WebRTC" is not a single protocol, rather a suite of protocols in >> concert. >> E.g., we got >> (DTLS)-connection-endpoints, >> (SCTP)-connection-endpoints, >> (UDP)-connection-endpoints, >> (RTP)-connection-endpoints, >> etc >> within an WebRTC entity. >> >> Two cents from my side, of course you may always expand these OSI-ISO >> base terms towards an (WebRTC)-endpoint (by highlighting the service >> access point aspects and the "(WebRTC)-connection" concept). >> >> -Albrecht >> >> >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >> Alvestrand >> Sent: Mittwoch, 15. Oktober 2014 11:40 >> To: Rauschenbach, Uwe (NSN - DE/Munich); ext Parthasarathi R; 'Christer >> Holmberg'; rtcweb@ietf.org >> Subject: Re: [rtcweb] Definitions of WebRTC entities >> >> On 10/15/2014 10:47 AM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: >>> Hi Harald, >>> >>> I wonder whether we can simplify the set of terms by removing "WebRTC >> endpoint". >> >> The reason for adding it was that it was already used in the RTCWEB RTP >> document, in harmony with the usage of "endpoint" in other RTP-releated >> specs. >> >> I'll take others' input on whether it's worth removing the term or >> keeping it. >> >> Note - from a strictly formalistic point of view, replacing all >> occurences of "WebRTC device" with "WebRTC endpoint" would have exactly >> the same effect. But the terms feel more comfortable to use in >> different contexts. >> >>> What was the reason for introducing the term "WebRTC endpoint"? >> Wouldn't it be enough to have "WebRTC UA", "WebRTC device" and "WebRTC- >> compatible device" (plus WebRTC gateway as special widespread case of >> compatible device)? >>> >>> A slight change in the chain of terms in -overview-12 could reduce >> the number of definitions without losing meaning (I think): >>> >>> 1) A WebRTC User Agent (also called a WebRTC UA or a WebRTC browser) >> is something that conforms to both the protocol specification and the >> Javascript API defined above. A WebRTC User Agent conforms to both the >> protocol specification and the Javascript API. >>> --> keep as is >>> >>> 2) A WebRTC device is something that conforms to the protocol >> specification, but does not claim to implement the Javascript API. >>> --> replace "claim" by "have". This results in IS-A >> and we can pull out "WebRTC endpoint". (This is also >> better in line than the current chain with the statement in the draft >> "All WebRTC browsers (UAs) are WebRTC devices, so any requirement on a >> WebRTC device also applies to a WebRTC browser" >>> 3) A WebRTC endpoint is either a WebRTC User Agent or a WebRTC >> device. >>> --> delete >>> >>> 4) A WebRTC-compatible endpoint is an endpoint that is capable of >> successfully communicating with a WebRTC endpoint, but may fail to meet >> some requirements of a WebRTC endpoint. This may limit where in the >> network such an endpoint can be attached, or may limit the security >> guarantees that it offers to others. >>> --> replace "endpoint" by "device" >>> >>> 5) A WebRTC gateway is a WebRTC-compatible endpoint that mediates >> traffic to non-WebRTC entities. >>> --> replace "endpoint" by "device" >>> >>> Kind regards, >>> Uwe >>> >>> >>> >>>> -----Original Message----- >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext >>>> Parthasarathi R >>>> Sent: Wednesday, October 15, 2014 2:30 AM >>>> To: 'Harald Alvestrand'; 'Christer Holmberg'; rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Definitions of WebRTC entities >>>> >>>> Hi Harald, >>>> >>>> >>>>>>> 2) It is not required to be endpoint but it shall be middle box. >>>>>> What do you mean by "middle box"? Again, that term is slippery. >>>>> I intent to say that the entity which is between two >>>>> endpoints and it does not end any media session itself. Here, The >>>>> confusion is that WebRTC compatible endpoint which is not an >>>>> endpoint but it is a middle box. >>>> Seems that this entity (whatever it's called) isn't an endpoint at >>>> all, so defining terms for endpoints shouldn't be relevant to >>>> whatever this device is. >>>> >>>> There's always more boxes in the middle..... although as long as >> they >>>> don't have the DTLS keys, it's limited what they can do to the >> packets. >>>> >>>> >>>> Could you please update the terminology as "WebRTC compatible >> device" >>>> instead of WebRTC compatible endpoint as the entity is not required >>>> to be endpoint. >>>> >>>> Thanks >>>> Partha. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>> Sent: Thursday, October 09, 2014 12:29 PM >>>>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] Definitions of WebRTC entities >>>>> >>>>> On 10/08/2014 06:39 PM, Parthasarathi R wrote: >>>>>> Hi Harald, >>>>>> >>>>>> Please read inline. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>>>> Sent: Tuesday, October 07, 2014 10:16 PM >>>>>>> To: Parthasarathi R; 'Christer Holmberg'; rtcweb@ietf.org >>>>>>> Subject: Re: [rtcweb] Definitions of WebRTC entities >>>>>>> >>>>>>> On 10/07/2014 06:21 PM, Parthasarathi R wrote: >>>>>>>> Hi Christer, >>>>>>>> >>>>>>>> I have no issue with WebRTC User Agent, WebRTC device, WebRTC >>>>>>> endpoint. >>>>>>>> I have bit trouble with WebRTC compatible endpoint as a entity >>>> name >>>>>>> as >>>>>>>> 1) It may pass SRTP/data channel >>>>>>> What do you mean by "pass"? That's a slippery term. >>>>>> "relay" will be more appropriate term as mentioned in Sec >>>> 5 >>>>> Para 2 of draft-alvestrand-rtcweb-gateways. >>>>>>>> 2) It is not required to be endpoint but it shall be middle box. >>>>>>> What do you mean by "middle box"? Again, that term is slippery. >>>>>> I intent to say that the entity which is between two >>>>> endpoints and it does not end any media session itself. Here, The >>>>> confusion is that WebRTC compatible endpoint which is not an >>>>> endpoint but it is a middle box. >>>>> >>>>> Seems that this entity (whatever it's called) isn't an endpoint at >>>> all, >>>>> so defining terms for endpoints shouldn't be relevant to whatever >>>> this >>>>> device is. >>>>> >>>>> There's always more boxes in the middle..... although as long as >>>>> they don't have the DTLS keys, it's limited what they can do to the >>>> packets. >>>>> >>>>>>>> WebRTC gateway looks more appropriate entity name in those >>>>> scenarios. >>>>>>> As written in my proposal, a WebRTC gateway is a WebRTC >> compatible >>>>>>> endpoint. >>>>>>> >>>>>> As per your proposal, we need to define WebRTC compatible >>>>> endpoint first which is super set of WebRTC gateway. Then, we need >>>>> to clarify which kind of WebRTC compatible endpoint qualify as >>>>> WebRTC gateway. But Christer wishes to have only two definition >>>> (Full/Subset). >>>>> >>>>> >>>>> And I don't agree with Christer, so then we're two :-) >>>> _______________________________________________ >>>> 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 nobody Wed Oct 15 11:40:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B551A90D3 for ; Wed, 15 Oct 2014 11:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muSo3eoPAYxp for ; Wed, 15 Oct 2014 11:39:55 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3EC1A90CC for ; Wed, 15 Oct 2014 11:39:54 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so2041930wgh.10 for ; Wed, 15 Oct 2014 11:39:53 -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=xXBCH5fbT6jRHiASmQXABOlAmx3Or20wxHG5KI42jCA=; b=FoORyq/ndaavo95rMVMgpPGcFyFs6/gkDRh909AL3Btjpq+tg2PqBhSb7ez19OEx7J sbPknhtxFQZZHlAPhuUOoCbUXfzqWz4IKm1l/WVFL0A9kCrRaNTEkHBCr67IzqWwOCh9 6ZHnJO6gOLdQr2L4K+JqlJvNVtN8c+2bQRxVYEuBDiVDtX3miYOMpMlRy8fJiprydtLF NrC/zFSKJH3Lz0VuAfDotFMnIWHjXOfFknP+OgJJvD95MiFsBdADg6SclrkynXAC89bP lxd2fEfGndqW0hRo25rU1fv0zFPEfc8zDzezsWs8wRx+pOHUpEhBYDAJahhH4b61T/k4 GdvA== X-Received: by 10.194.103.74 with SMTP id fu10mr14953427wjb.0.1413398393140; Wed, 15 Oct 2014 11:39:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.134.196 with HTTP; Wed, 15 Oct 2014 11:39:31 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Wed, 15 Oct 2014 11:39:31 -0700 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=089e010d7fb826414f05057a75bb Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0K8WvYYl6m-scB8loiPQjVrBduk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 18:39:58 -0000 --089e010d7fb826414f05057a75bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Are we actually going to spend time discussing draft-ietf-rtcweb-video (which will provide the details on what is necessary for video implementations of any codec), or will yet another MTI discussion take up all the energy (and perhaps time)? On Wed, Oct 15, 2014 at 10:10 AM, Ted Hardie wrote: > Hi Victor, > > As you may remember, we tabled discussion of video codecs back in January= , > and said that the topic could be re-opened 6 weeks prior to IETF 91. We = do > anticipate discussing it at this meeting, likely in the Thursday slot > (since there is a related BoF earlier that day). > > regards, > > Ted Hardie > > On Wed, Oct 15, 2014 at 7:20 AM, Victor Pascual Avila < > victor.pascual.avila@gmail.com> wrote: > >> I surely missed a recent thread on it but, any plan to discuss MTI >> Video Codec in HI? >> >> I read in Jonathan's post it's part of the agenda? >> http://blogs.cisco.com/collaboration/ciscos-openh264-now-part-of-firefox= / >> >> Cheers, >> -Victor >> >> On Wed, Sep 11, 2013 at 7:51 PM, Victor Pascual Avila >> wrote: >> > Thanks for the feedback Ted! >> > >> > On Wed, Sep 11, 2013 at 7:48 PM, Ted Hardie wrote= : >> >> Hi Victor, >> >> >> >> The chairs have been discussion the structure of the upcoming meeting= , >> and >> >> you should expect something from us soon. >> >> >> >> thanks, >> >> >> >> Ted >> >> >> >> >> >> On Tue, Sep 10, 2013 at 6:47 AM, Victor Pascual Avila >> >> wrote: >> >>> >> >>> Dear WG Chairs, >> >>> >> >>> What's the plan for the MTI video codec discussion? Are we planning = to >> >>> discuss this during our next meeting? Is there a reason to delay thi= s >> >>> decision? >> >>> >> >>> My apologies if this has already been discussed but could not find i= t >> >>> in the archives. >> >>> >> >>> Thanks, >> >>> -Victor >> >>> _______________________________________________ >> >>> rtcweb mailing list >> >>> rtcweb@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> > >> > >> > >> > -- >> > Victor Pascual =C3=81vila >> >> >> >> -- >> Victor Pascual =C3=81vila >> >> _______________________________________________ >> 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 > > --089e010d7fb826414f05057a75bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Are we actually going to spend time discussing draft-ietf-= rtcweb-video (which will provide the details on what is necessary for video= implementations of any codec), or will yet another MTI discussion take up = all the energy (and perhaps time)?=C2=A0


On Wed, Oct 15, 2014= at 10:10 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
Hi Victor,

As you may remember, we tabled discussion of video codecs bac= k in January, and said that the topic could be re-opened 6 weeks prior to I= ETF 91.=C2=A0 We do anticipate discussing it at this meeting, likely in the= Thursday slot (since there is a related BoF earlier that day).

regards,

Ted Hardie

On Wed, Oct 15, 2014 at 7:20 AM, Victor Pascual Avila &= lt;vict= or.pascual.avila@gmail.com> wrote:
I surely missed a recent thread on it but, any plan to discuss MTI<= br> Video Codec in HI?

I read in Jonathan's post it's part of the agenda?
http://blogs.cisco.com/collaboration/ciscos-op= enh264-now-part-of-firefox/

Cheers,
-Victor

On Wed, Sep 11, 2013 at 7:51 PM, Victor Pascual Avila
<victor.pascual.avila@gmail.com> wrote:
> Thanks for the feedback Ted!
>
> On Wed, Sep 11, 2013 at 7:48 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> Hi Victor,
>>
>> The chairs have been discussion the structure of the upcoming meet= ing, and
>> you should expect something from us soon.
>>
>> thanks,
>>
>> Ted
>>
>>
>> On Tue, Sep 10, 2013 at 6:47 AM, Victor Pascual Avila
>> <victor.pascual.avila@gmail.com> wrote:
>>>
>>> Dear WG Chairs,
>>>
>>> What's the plan for the MTI video codec discussion? Are we= planning to
>>> discuss this during our next meeting? Is there a reason to del= ay this
>>> decision?
>>>
>>> My apologies if this has already been discussed but could not = find it
>>> in the archives.
>>>
>>> Thanks,
>>> -Victor
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
>
> --
> Victor Pascual =C3=81vila



--
Victor Pascual =C3=81vila

_______________________________________________
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


--089e010d7fb826414f05057a75bb-- From nobody Thu Oct 16 01:32:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05F61A1AE0 for ; Thu, 16 Oct 2014 01:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wesbwMhb2vt1 for ; Thu, 16 Oct 2014 01:32:31 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB5B1A1ABA for ; Thu, 16 Oct 2014 01:32:31 -0700 (PDT) Received: from [81.187.2.149] (port=37442 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XegU1-00015O-Pv; Thu, 16 Oct 2014 09:32:30 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <543EAE51.1060508@alvestrand.no> Date: Thu, 16 Oct 2014 09:32:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5550CFCE-F6AC-4279-ABBF-17EB7E95B416@csperkins.org> References: <542E53D2.5040500@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D465376@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465985@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D465A34@ESESSMB209.ericsson.se> <00f501cfe24a$b8515930$28f40b90$@co.in> <543418D5.8010509@alvestrand.no> <006301cfe316$6d3c5590$47b500b0$@co.in> <54363216.3060700@alvestrand.no> <010d01cfe80f$1c8e3930$55aaab90$@co.in> <56C2F665D49E0341B9DF5938005ACDF8194C0459@DEMUMBX005.nsn-intra.net> <543E40E7.4030609@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC3418E0@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF8194C1087@DEMUMBX005.nsn-intra.net> <543EAE51.1060508@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/P7_vom735Or8cLcOhrrmMTVnysw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Definitions of WebRTC entities X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 08:32:35 -0000 On 15 Oct 2014, at 18:26, Harald Alvestrand = wrote: > On 10/15/2014 06:55 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: >> Hi Harald, all, >>=20 >> I concur with Albrecht w.r.t. the meaning of "WebRTC endpoint". You = mention below that "endpoint" is included mainly because it is used in = the rtp-usage draft. But an "RTP endpoint" (a source and/or destination = of RTP streams) may be different from a "WebRTC endpoint" (e.g. a mixing = device). > To be more precise: The term "WebRTC endpoint" is used in the = rtp-usage draft. Three times. >>=20 >> I believe that in the RTP usage draft, the meaning of "endpoint" is = usually "RTP endpoint" with the interpretation "RTP endpoint that = supports WebRTC". Terms used as well are "WebRTC implementations of RTP = endpoints" and "WebRTC implementation". If we interpret "endpoint" that = way, and maybe do some editorial update of -rtp-usage replacing "WebRTC = endpoint" with "WebRTC implementation" or "WebRTC-aware endpoint" (I can = volunteer to write a proposal), there will be no clash with the proposal = to drop "WebRTC endpoint" from -overview. >=20 > =93WebRTC implementation" is defined nowhere, so I'm happy to have = that term removed from service. Once we decide on the desired terms, we can align the RTP usage draft = with them.=20 >> The more neutral "device" for WebRTC entities allows to include = entities that may not be the original source or final sink of RTP media = streams. "Entity" would be an alternative for "Device" but I seem to = recall there was dislike for that term previously. >=20 > I would be happy to exclude devices that are participating in, but not = terminating, an RTP session (such as RTP translators and other = quasi-multicast devices) from consideration in this set of documents. >=20 > I think we already have strong advice against them: >=20 > "This limitation means that > some of the RTP middlebox-based topologies are not suitable for use > in the WebRTC environment. Specifically: >=20 > o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, > since they make the use of RTCP for congestion control and = quality > of service reports problematic (see Section 3.8 of > [I-D.ietf-avtcore-rtp-topologies-update]). >=20 > o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology > SHOULD NOT be used because its safe use requires a congestion > control algorithm or RTP circuit breaker that handles point to > multipoint, which has not yet been standardised. >=20 > " >=20 > If we were to start talking about them, this is a topic of far more = wide-ranging debate than mere terminology. There are allowed topologies with RTP mixers and translators where a = device participates in, but does not terminate, an RTP session, and the = RTP usage draft needs to refer to such middleboxes in places. I=92m not = sure we need a WebRTC-specific term for such a middlebox for the RTP = usage draft, though. --=20 Colin Perkins https://csperkins.org/ From nobody Thu Oct 16 10:11:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8911A19E8 for ; Thu, 16 Oct 2014 10:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCA-WP4-zEM8 for ; Thu, 16 Oct 2014 10:10:51 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3C41A0384 for ; Thu, 16 Oct 2014 10:10:51 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id x19so3888961ier.39 for ; Thu, 16 Oct 2014 10:10:50 -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=sfaSeVKAhYt9lbmClT3B67rcAiOD8xJgj+9kV949Gdg=; b=Xsby4XAtuDOvGnTd0rmWr+x4xEpM327rECq2pDNm0LQKbPCkOHwd4xVcqnx/TBLWPm sakSYROtwZchKwEehyMW3LbKL65KpMeJTfmwMFAW1FTSwzKkTWZUl9rQJqvrroGeytlA Ylzkvm+F1sIhSol/T9MTAUsZs+cMptRU9LmEVBXeKg2lPf/WV/mEsiGTy0ao5cUpeA0l YZwjrOMo0TrwYRFteIFmrky4b06E0cYQY01zLSJV4Uh10MX11ChgMgaPiQ9mUHfW9gcB 43H/UurEOQB4tudMAmHmYjjaR6gQGDdZqpSacWMoKyZyZi+rfkuaDtpmysvv1ZnKM+6M uQXQ== MIME-Version: 1.0 X-Received: by 10.43.90.198 with SMTP id bj6mr5476817icc.4.1413479450713; Thu, 16 Oct 2014 10:10:50 -0700 (PDT) Received: by 10.43.3.4 with HTTP; Thu, 16 Oct 2014 10:10:50 -0700 (PDT) Date: Thu, 16 Oct 2014 10:10:50 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec5196bdd8ea2d605058d543e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t-NlNTEJXB5yzfmoKfWbzddz01U Subject: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 17:10:56 -0000 --bcaec5196bdd8ea2d605058d543e Content-Type: text/plain; charset=UTF-8 During this morning chairs call, we discussed the agenda for the upcoming meeting. The two big items are JSEP and the video codec discussion, and our current thought is to have the JSEP discussion on Monday and the video codec discussion on Thursday. There are a number of items we may need to discuss; if there are particular issues you feel we need to cover, please send a message to the list with the topic and the amount of time you feel you need. thanks, Ted, Cullen, Sean --bcaec5196bdd8ea2d605058d543e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
During this morning chairs call, we discussed th= e agenda for the upcoming meeting.=C2=A0 The two big items are JSEP and the= video codec discussion, and our current thought is to have the JSEP discus= sion on Monday and the video codec discussion on Thursday.=C2=A0 There are = a number of items we may need to discuss; if there are particular issues yo= u feel we need to cover, please send a message to the list with the topic a= nd the amount of time you feel you need.

thanks,

Ted, Cullen,= Sean
--bcaec5196bdd8ea2d605058d543e-- From nobody Thu Oct 16 10:21:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AD51A1B0E for ; Thu, 16 Oct 2014 10:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhUJMpWmDUiR for ; Thu, 16 Oct 2014 10:21:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B381A1B0B for ; Thu, 16 Oct 2014 10:21:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-48-543ffe94b955 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 81.9B.04387.49EFF345; Thu, 16 Oct 2014 19:21:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 19:21:24 +0200 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" , "Sean Turner" , Cullen Jennings Thread-Topic: [rtcweb] Agenda for the upcoming meeting Thread-Index: AQHP6WQuhkLeniShFUWNzyy1Y85X7pwy9+sg Date: Thu, 16 Oct 2014 17:21:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47FFC5@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D47FFC5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3RnfKP/sQgxMz1C06JrNZrP3Xzm7R ONfOYse5CSwOLB5Tfm9k9dg56y67x505H1g9liz5yRTAEsVlk5Kak1mWWqRvl8CVsbpzGVPB HNeKDW8OsDQwLnHuYuTgkBAwkWjv5+ti5AQyxSQu3FvP1sXIxSEkcJRR4tmD14wQzhJGiYct T5hBGtgELCS6/2mDxEUEJjBKXPm2nhmkW1jAVGLaz4MsILaIgJnEmx2/2CBsI4lrt+8wgdgs AqoSv7+8A7N5BXwlel/sYwGZKSQQINHbpwES5hQIlDh/rZcRxGYEOuj7qTVg5cwC4hK3nsxn gjhUQGLJnvPMELaoxMvH/1ghbCWJxiVPWEFGMgvkS3w/LgexSVDi5MwnLBMYRWYhmTQLoWoW kiqIsKbE+l36ENWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxaXJybbmSkl1qUmVxcnJ+nl5da sokRGHMHt/y22sF48LnjIUYBDkYlHt4HcfYhQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5Ykpqd mlqQWhRfVJqTWnyIkYmDU6qBMWtptXfHK5PAz3L3Pl11+Vi6+Mf7oLLgWtEV4oLtnMf+sWyr +G68SKivbpJBNMvioJJuNb5XBhNv3VvgxX7x9B2Fv/qH9b4s5en+/KHoq/kfP0XN7MTTz3wU X64Wcb+Qc37+rZT+ClmfM5ct0zami5WYW2Vy7eApm+/c6iLAbjrZySHvsvdVJZbijERDLeai 4kQA3uO6r5oCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/T3T-C_Y1wEfMFikFOfwOpdVKssA Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 17:21:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D47FFC5ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFub3RoZXIgaXNzdWUgdGhhdCBtdXN0IGJlIHNvbHZlZCBpcyB0aGUgRGF0YSBDaGFu bmVsIHN0cmVhbSBpZCBpc3N1ZSB0aGF0IGlzIGN1cnJlbnRseSBiZWluZyBkaXNjdXNzZWQuDQoN CkhvcGVmdWxseSBpdCBjYW4gYmUgc29sdmVkIG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUgbWVldGlu ZywgYnV0IGp1c3QgaW4gY2FzZSBpdCBjYW7igJl04oCmDQoNCldlIGhhdmUgYSBkZXBlbmRlbmN5 IG9uIHRoYXQgaXNzdWUgYWxzbyBpbiBDTFVFLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpG cm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFRlZCBIYXJkaWUNClNlbnQ6IDE2IE9jdG9iZXIgMjAxNCAyMDoxMQ0KVG86IHJ0Y3dlYkBpZXRm Lm9yZzsgU2VhbiBUdXJuZXI7IEN1bGxlbiBKZW5uaW5ncw0KU3ViamVjdDogW3J0Y3dlYl0gQWdl bmRhIGZvciB0aGUgdXBjb21pbmcgbWVldGluZw0KDQpEdXJpbmcgdGhpcyBtb3JuaW5nIGNoYWly cyBjYWxsLCB3ZSBkaXNjdXNzZWQgdGhlIGFnZW5kYSBmb3IgdGhlIHVwY29taW5nIG1lZXRpbmcu ICBUaGUgdHdvIGJpZyBpdGVtcyBhcmUgSlNFUCBhbmQgdGhlIHZpZGVvIGNvZGVjIGRpc2N1c3Np b24sIGFuZCBvdXIgY3VycmVudCB0aG91Z2h0IGlzIHRvIGhhdmUgdGhlIEpTRVAgZGlzY3Vzc2lv biBvbiBNb25kYXkgYW5kIHRoZSB2aWRlbyBjb2RlYyBkaXNjdXNzaW9uIG9uIFRodXJzZGF5LiAg VGhlcmUgYXJlIGEgbnVtYmVyIG9mIGl0ZW1zIHdlIG1heSBuZWVkIHRvIGRpc2N1c3M7IGlmIHRo ZXJlIGFyZSBwYXJ0aWN1bGFyIGlzc3VlcyB5b3UgZmVlbCB3ZSBuZWVkIHRvIGNvdmVyLCBwbGVh c2Ugc2VuZCBhIG1lc3NhZ2UgdG8gdGhlIGxpc3Qgd2l0aCB0aGUgdG9waWMgYW5kIHRoZSBhbW91 bnQgb2YgdGltZSB5b3UgZmVlbCB5b3UgbmVlZC4NCg0KdGhhbmtzLA0KDQpUZWQsIEN1bGxlbiwg U2Vhbg0K --_000_7594FB04B1934943A5C02806D1A2204B1D47FFC5ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1 NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5Bbm90aGVyIGlzc3VlIHRoYXQgbXVzdCBiZSBzb2x2ZWQgaXMgdGhlIERhdGEg Q2hhbm5lbCBzdHJlYW0gaWQgaXNzdWUgdGhhdCBpcyBjdXJyZW50bHkgYmVpbmcgZGlzY3Vzc2Vk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+SG9wZWZ1bGx5IGl0IGNhbiBiZSBzb2x2ZWQgb24gdGhlIGxpc3QgYmVmb3JlIHRo ZSBtZWV0aW5nLCBidXQganVzdCBpbiBjYXNlIGl0IGNhbuKAmXTigKY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldlIGhhdmUg YSBkZXBlbmRlbmN5IG9uIHRoYXQgaXNzdWUgYWxzbyBpbiBDTFVFLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBIYXJkaWU8YnI+DQo8Yj5TZW50 OjwvYj4gMTYgT2N0b2JlciAyMDE0IDIwOjExPGJyPg0KPGI+VG86PC9iPiBydGN3ZWJAaWV0Zi5v cmc7IFNlYW4gVHVybmVyOyBDdWxsZW4gSmVubmluZ3M8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0 Y3dlYl0gQWdlbmRhIGZvciB0aGUgdXBjb21pbmcgbWVldGluZzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkR1cmluZyB0aGlzIG1vcm5pbmcg Y2hhaXJzIGNhbGwsIHdlIGRpc2N1c3NlZCB0aGUgYWdlbmRhIGZvciB0aGUgdXBjb21pbmcgbWVl dGluZy4mbmJzcDsgVGhlIHR3byBiaWcgaXRlbXMgYXJlIEpTRVAgYW5kIHRoZSB2aWRlbyBjb2Rl YyBkaXNjdXNzaW9uLCBhbmQgb3VyIGN1cnJlbnQgdGhvdWdodCBpcyB0byBoYXZlIHRoZSBKU0VQ IGRpc2N1c3Npb24NCiBvbiBNb25kYXkgYW5kIHRoZSB2aWRlbyBjb2RlYyBkaXNjdXNzaW9uIG9u IFRodXJzZGF5LiZuYnNwOyBUaGVyZSBhcmUgYSBudW1iZXIgb2YgaXRlbXMgd2UgbWF5IG5lZWQg dG8gZGlzY3VzczsgaWYgdGhlcmUgYXJlIHBhcnRpY3VsYXIgaXNzdWVzIHlvdSBmZWVsIHdlIG5l ZWQgdG8gY292ZXIsIHBsZWFzZSBzZW5kIGEgbWVzc2FnZSB0byB0aGUgbGlzdCB3aXRoIHRoZSB0 b3BpYyBhbmQgdGhlIGFtb3VudCBvZiB0aW1lIHlvdSBmZWVsIHlvdSBuZWVkLjxicj4NCjxicj4N CnRoYW5rcyw8YnI+DQo8YnI+DQpUZWQsIEN1bGxlbiwgU2VhbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D47FFC5ESESSMB209erics_-- From nobody Thu Oct 16 14:17:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65B11A8881 for ; Thu, 16 Oct 2014 14:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30qKy35fJvbj for ; Thu, 16 Oct 2014 14:17:20 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 8D19D1A882F for ; Thu, 16 Oct 2014 14:17:20 -0700 (PDT) Received: from [IPv6:2001:5a8:4:39d0:d5fe:6e06:c62e:6418] (unknown [IPv6:2001:5a8:4:39d0:d5fe:6e06:c62e:6418]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 3AAEE4A047A for ; Thu, 16 Oct 2014 14:17:18 -0700 (PDT) Message-ID: <544035DE.8000606@matthew.at> Date: Thu, 16 Oct 2014 14:17:18 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050307000004080905020408" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/piTAXF2pw6FcmWTWSAud7F_qyBk Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 21:17:22 -0000 This is a multi-part message in MIME format. --------------050307000004080905020408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/15/2014 10:10 AM, Ted Hardie wrote: > Hi Victor, > > As you may remember, we tabled discussion of video codecs back in > January, and said that the topic could be re-opened 6 weeks prior to > IETF 91. We do anticipate discussing it at this meeting, likely in > the Thursday slot (since there is a related BoF earlier that day). > And that's because something substantive has changed, or simply because wasting the WG time on this again is more entertaining than actually finishing a specification that can be independently implemented by all browser vendors? (A specification that we are nowhere near having, as far as I can tell) Matthew Kaufman --------------050307000004080905020408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/15/2014 10:10 AM, Ted Hardie wrote:
Hi Victor,

As you may remember, we tabled discussion of video codecs back in January, and said that the topic could be re-opened 6 weeks prior to IETF 91.  We do anticipate discussing it at this meeting, likely in the Thursday slot (since there is a related BoF earlier that day).


And that's because something substantive has changed, or simply because wasting the WG time on this again is more entertaining than actually finishing a specification that can be independently implemented by all browser vendors? (A specification that we are nowhere near having, as far as I can tell)

Matthew Kaufman


--------------050307000004080905020408-- From nobody Thu Oct 16 14:28:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A121A89A8 for ; Thu, 16 Oct 2014 14:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kSfqkf0X3DT for ; Thu, 16 Oct 2014 14:28:11 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058F01A88D7 for ; Thu, 16 Oct 2014 14:28:10 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so3572777lbg.28 for ; Thu, 16 Oct 2014 14:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K/0FpVvXIUDDitDUwKd3t8rv7UU5ZzJfAMz2D//UB/M=; b=IXCX3mwYn5+kaguvesB1DvtXyJkVISE+M1kZ6Zi0dfjobV9MHsy7HahKPWPWg/tA/F t3vhPTVsPLpyFbRmdEtHQW/mfdWiAjXyeLnHBGMDGp3K2dSgsrJOM+K/nLolSVtQx3Er UcjQe81iks6gHjHjzzsZeMtvwinbIi8Upr3S1tVepHirI/0W2p94FsgzSH3mEOVjWqH4 FvmgsnI56RMSSRE2x0hOXwnO17wQmL4kcYKtd2I/8gaUd87/IX454kG5Zuyz85bVvbeq 8KDNK3HDMUnxYk1Kbj06Lae+/dtczLZ37y/U4jmtQIcRlE8d0uY95OVRx6qba+mzuHTY jmuQ== MIME-Version: 1.0 X-Received: by 10.152.204.103 with SMTP id kx7mr4406273lac.7.1413494889334; Thu, 16 Oct 2014 14:28:09 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Thu, 16 Oct 2014 14:28:09 -0700 (PDT) In-Reply-To: <544035DE.8000606@matthew.at> References: <544035DE.8000606@matthew.at> Date: Thu, 16 Oct 2014 14:28:09 -0700 Message-ID: From: Martin Thomson To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2wWfIWHNxGVvXBY85tEvu1WwI_k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 21:28:19 -0000 On 16 October 2014 14:17, Matthew Kaufman wrote: > And that's because something substantive has changed, or simply because > wasting the WG time on this again is more entertaining than actually > finishing a specification that can be independently implemented by all > browser vendors? (A specification that we are nowhere near having, as far as > I can tell) Personally, I've found the reprieve from this fight refreshing. And it would appear that we've made some real progress as a result. I'd suggest that if we don't have new information, we continue to spend our time productively. If we can't find topics to occupy our meeting agenda time, then maybe we can free an agenda slot. From nobody Thu Oct 16 14:35:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6891A8AA3 for ; Thu, 16 Oct 2014 14:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pF0eYG4j-44 for ; Thu, 16 Oct 2014 14:35:47 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A73D1A88D7 for ; Thu, 16 Oct 2014 14:35:47 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id tr6so4360549ieb.33 for ; Thu, 16 Oct 2014 14:35:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aGZwVL3aN/s2PVyOKcAkNDYdeIIrL57KIp3lEsJt0XY=; b=cWSpAzsPauabKRSQ2Pz52hq+HXY3XDrcqVB9xCNLeMaQaVKOL11UOhausg0fqXG7Xb ymsgk5Q9IqQllTZQqPV+QZAuIMA1Y4IJJa3aCKdJzBSMHWAnL10bv2Pbyu4ACVg/Mj9V cmXxQfyxCWNj/tYXujASFMSuDA+JVH7LMzaKqeeWMOCxseK8CKo1fQrymj3c3b1XYauS fdQkxLyxbAqj103X1or5MDjq8sfQoWcDPB9Tmh/BsDe1wsxzbgmcmGJ8Zf/aioXke3rf lgdnkOSUcKicgid/x/p8U4B8JS/s+DxglPvYW0KvJARxMuH4wvx7PMIq5LR3RT2pQg7l 8aOQ== X-Gm-Message-State: ALoCoQkffzaosOpyTsy8wK1PSjWhmrYF6ECgVWa3lEIOq4kpvlY11TM3Tb89bqmZqUWrvYrSLtFI X-Received: by 10.43.106.206 with SMTP id dv14mr6739213icc.6.1413495346399; Thu, 16 Oct 2014 14:35:46 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d5sm3618954ioj.30.2014.10.16.14.35.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 14:35:45 -0700 (PDT) Message-ID: <54403A31.8030309@andyet.net> Date: Thu, 16 Oct 2014 15:35:45 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson , Matthew Kaufman References: <544035DE.8000606@matthew.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fvQaW9LTyaL89uQYoA4a9DPlZ7w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 21:35:48 -0000 On 10/16/14, 3:28 PM, Martin Thomson wrote: > On 16 October 2014 14:17, Matthew Kaufman wrote: >> And that's because something substantive has changed, or simply because >> wasting the WG time on this again is more entertaining than actually >> finishing a specification that can be independently implemented by all >> browser vendors? (A specification that we are nowhere near having, as far as >> I can tell) > > Personally, I've found the reprieve from this fight refreshing. And > it would appear that we've made some real progress as a result. I'd > suggest that if we don't have new information, we continue to spend > our time productively. +1 As I said here on January 28th: "IMHO the state of video codec development needs to evolve before the WG can make a decision regarding an MTI video codec." As far as I can see, it is still too early to take up the MTI video codec issue again, and I urge the WG to continue working on tractable problems. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Oct 16 15:02:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5047C1A8AB8 for ; Thu, 16 Oct 2014 15:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Axf-Ou-iv5O for ; Thu, 16 Oct 2014 15:02:36 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E041A8029 for ; Thu, 16 Oct 2014 15:02:36 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id fp1so3943035pdb.25 for ; Thu, 16 Oct 2014 15:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=AqbAsSCysaC6nvXyYlBlvuoQcZCAhQ00L5WTak+bYKo=; b=zUQP5Gyfv5mDA/B+S1YvCNfXIVB76NL3RMI6ZxjyblHtoNjenldBHvPj3Ra5wJpzcH y7O+xD630h2bA3//NB5QkbAzgmkX329NHSfa8FQnPEn0xX9p4h1e4JcbnuCOCw/JVd9Z JtGliVQDFrh9DwLal07d3fZ/UmaLfD8/7clgowsWGXGgUxe36/ucnvmVDCB+GfcbzQX1 wvzzC5ZE02I3Ry9JngkkX7GuRJ8+cP480ItWbW2dlG4ieDqLlAwBE+dqUlstwjpE/shi kzOBuPP71kQ7yfNboN+6R2IEVIeiIiYPo6yVZSamUkWZ5UKLrOuSkXKKu/PLEyOHdHC0 EGdA== X-Received: by 10.68.219.164 with SMTP id pp4mr4000896pbc.143.1413496956150; Thu, 16 Oct 2014 15:02:36 -0700 (PDT) Received: from [10.7.5.253] (mobile-166-137-212-118.mycingular.net. [166.137.212.118]) by mx.google.com with ESMTPSA id 16sm20656851pdj.42.2014.10.16.15.02.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 15:02:34 -0700 (PDT) References: <544035DE.8000606@matthew.at> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12A405) From: Bernard Aboba Date: Thu, 16 Oct 2014 15:02:30 -0700 To: Martin Thomson Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bvW7qk0MTrUmwWlJLSsBatFrpnU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 22:02:38 -0000 One thing we could do instead of wasting time on MTI is to actually make pro= gress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually= interoperate regardless of the codec. > On Oct 16, 2014, at 2:28 PM, Martin Thomson wro= te: >=20 >> On 16 October 2014 14:17, Matthew Kaufman wrote: >> And that's because something substantive has changed, or simply because >> wasting the WG time on this again is more entertaining than actually >> finishing a specification that can be independently implemented by all >> browser vendors? (A specification that we are nowhere near having, as far= as >> I can tell) >=20 > Personally, I've found the reprieve from this fight refreshing. And > it would appear that we've made some real progress as a result. I'd > suggest that if we don't have new information, we continue to spend > our time productively. If we can't find topics to occupy our meeting > agenda time, then maybe we can free an agenda slot. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Oct 16 15:41:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3181A8848 for ; Thu, 16 Oct 2014 15:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpVez08uh4dx for ; Thu, 16 Oct 2014 15:41:12 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4777C1A87A4 for ; Thu, 16 Oct 2014 15:41:12 -0700 (PDT) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 16 Oct 2014 15:30:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="401516178" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by FMSMGA003.fm.intel.com with ESMTP; 16 Oct 2014 15:33:32 -0700 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.73]) by fmsmsx104.amr.corp.intel.com ([169.254.4.49]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 15:40:50 -0700 From: "Cavigioli, Chris" To: Bernard Aboba , Martin Thomson Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP6YalvH0vdbAWv0eULyOYAeS/S5wzsnSAgAAJmQD//5R0IA== Date: Thu, 16 Oct 2014 22:40:50 +0000 Message-ID: References: <544035DE.8000606@matthew.at> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5csjb1fqpUPibYxxnU6L6Umh9ZQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 22:41:14 -0000 I completely agree. MTI is wasting time, given we know the industry is spl= it between H.xxx and VPxxx ... and given we know that H.264/VP8 will become= H.265/VP9 rapidly ... we need to ensure WebRTC works with various codecs a= nd guide the industry towards VP8, H.264, VP9, H.265 (not some other varian= t). There will be some vendors who support both formats and some who don't= . -chris=20 -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Thursday, October 16, 2014 3:03 PM To: Martin Thomson Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec. > On Oct 16, 2014, at 2:28 PM, Martin Thomson wr= ote: >=20 >> On 16 October 2014 14:17, Matthew Kaufman wrote: >> And that's because something substantive has changed, or simply=20 >> because wasting the WG time on this again is more entertaining than=20 >> actually finishing a specification that can be independently=20 >> implemented by all browser vendors? (A specification that we are=20 >> nowhere near having, as far as I can tell) >=20 > Personally, I've found the reprieve from this fight refreshing. And=20 > it would appear that we've made some real progress as a result. I'd=20 > suggest that if we don't have new information, we continue to spend=20 > our time productively. If we can't find topics to occupy our meeting=20 > agenda time, then maybe we can free an agenda slot. >=20 > _______________________________________________ > 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 nobody Thu Oct 16 15:51:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C391A8AD8 for ; Thu, 16 Oct 2014 15:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGBIsrck-Qcw for ; Thu, 16 Oct 2014 15:51:12 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4F51A8AD9 for ; Thu, 16 Oct 2014 15:50:46 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 2FB6AF39FB365; Thu, 16 Oct 2014 22:50:42 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9GMoiRJ019025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 18:50:45 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 18:50:44 -0400 From: "Makaraju, Maridi Raju (Raju)" To: "Cavigioli, Chris" , Bernard Aboba , Martin Thomson Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP6INH0YA0VVXvZkG/wkm6G20Ux5wzPCuvgABGBoCAAAmYAIAACrYA//+/dRA= Date: Thu, 16 Oct 2014 22:50:44 +0000 Message-ID: References: <544035DE.8000606@matthew.at> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Sjt3RKJgUosihqeM-6GSowarJK4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 22:51:14 -0000 + 1 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cavigioli, Chr= is > Sent: Thursday, October 16, 2014 5:41 PM > To: Bernard Aboba; Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Plan for MTI video codec? >=20 > I completely agree. MTI is wasting time, given we know the industry is > split between H.xxx and VPxxx ... and given we know that H.264/VP8 will > become H.265/VP9 rapidly ... we need to ensure WebRTC works with various > codecs and guide the industry towards VP8, H.264, VP9, H.265 (not some ot= her > variant). There will be some vendors who support both formats and some w= ho > don't. > -chris >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, October 16, 2014 3:03 PM > To: Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Plan for MTI video codec? >=20 > One thing we could do instead of wasting time on MTI is to actually make > progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could > actually interoperate regardless of the codec. >=20 >=20 >=20 > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: > > > >> On 16 October 2014 14:17, Matthew Kaufman wrote: > >> And that's because something substantive has changed, or simply > >> because wasting the WG time on this again is more entertaining than > >> actually finishing a specification that can be independently > >> implemented by all browser vendors? (A specification that we are > >> nowhere near having, as far as I can tell) > > > > Personally, I've found the reprieve from this fight refreshing. And > > it would appear that we've made some real progress as a result. I'd > > suggest that if we don't have new information, we continue to spend > > our time productively. If we can't find topics to occupy our meeting > > agenda time, then maybe we can free an agenda slot. > > > > _______________________________________________ > > 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Oct 16 15:54:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602411A8AEB for ; Thu, 16 Oct 2014 15:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3uynWsU46CQ for ; Thu, 16 Oct 2014 15:54:11 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48ED91A8AD8 for ; Thu, 16 Oct 2014 15:54:11 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hi2so662544wib.15 for ; Thu, 16 Oct 2014 15:54:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OvL2v1OdGrV86Z4RN9+0tJ79/c54Qu1yEj/XGFYw0H0=; b=d9FsOpjFEX0mTEB5CHywohAcmOwFBnm7LyTsacUbb42RKqSqeyXR2L1iROgZCZmexx ErqnvcJRo8eoIQEjO0PwDCPBKMnYM3Am55oKrLfn6vN+mvnBB6lz6CHQkytpixIhuXye 9UCmvQEsHj1cFYhQtIsg8vFVL4BW+4ka9GCCo3R8SlfIbBGKnICFcvSzz4vADxMbC1eR pHn/evqHg15QeT2rv9X1mksEyahLC8JhArI05y++JpXtqxYc+PQ7Aq1kyL6FBrrsIt5B LdEcKuU9V/0bx7d8paF6xg2JyqQvEysTq+1LKq5aAz6JLEHbaKNmX1AJYIlsu75AmHJc SZSQ== X-Gm-Message-State: ALoCoQkIjCdjvKzNbOEj6gOaRldjB2XXJytIREkMHbw4BeGvj8N8AI0JOQKOMrnHJrErot3jTvgZ X-Received: by 10.194.122.104 with SMTP id lr8mr5871487wjb.64.1413500049900; Thu, 16 Oct 2014 15:54:09 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx.google.com with ESMTPSA id y5sm3552265wix.10.2014.10.16.15.54.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 15:54:08 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so4788742wgh.23 for ; Thu, 16 Oct 2014 15:54:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.186.175 with SMTP id fl15mr9629716wic.38.1413500048379; Thu, 16 Oct 2014 15:54:08 -0700 (PDT) Received: by 10.216.176.65 with HTTP; Thu, 16 Oct 2014 15:54:08 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> Date: Thu, 16 Oct 2014 18:54:08 -0400 Message-ID: From: Roman Shpount To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=001a11339a6446161c05059220e2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xsBA1EW-AGXiYzERkUqoTD3IKqU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 22:54:14 -0000 --001a11339a6446161c05059220e2 Content-Type: text/plain; charset=UTF-8 +1 as well. There is nothing of consequence that changed since this discussion happened last time, so there is no possibility for the decision. _____________ Roman Shpount On Thu, Oct 16, 2014 at 6:50 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > + 1 > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cavigioli, > Chris > > Sent: Thursday, October 16, 2014 5:41 PM > > To: Bernard Aboba; Martin Thomson > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Plan for MTI video codec? > > > > I completely agree. MTI is wasting time, given we know the industry is > > split between H.xxx and VPxxx ... and given we know that H.264/VP8 will > > become H.265/VP9 rapidly ... we need to ensure WebRTC works with various > > codecs and guide the industry towards VP8, H.264, VP9, H.265 (not some > other > > variant). There will be some vendors who support both formats and some > who > > don't. > > -chris > > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba > > Sent: Thursday, October 16, 2014 3:03 PM > > To: Martin Thomson > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Plan for MTI video codec? > > > > One thing we could do instead of wasting time on MTI is to actually make > > progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could > > actually interoperate regardless of the codec. > > > > > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > > wrote: > > > > > >> On 16 October 2014 14:17, Matthew Kaufman wrote: > > >> And that's because something substantive has changed, or simply > > >> because wasting the WG time on this again is more entertaining than > > >> actually finishing a specification that can be independently > > >> implemented by all browser vendors? (A specification that we are > > >> nowhere near having, as far as I can tell) > > > > > > Personally, I've found the reprieve from this fight refreshing. And > > > it would appear that we've made some real progress as a result. I'd > > > suggest that if we don't have new information, we continue to spend > > > our time productively. If we can't find topics to occupy our meeting > > > agenda time, then maybe we can free an agenda slot. > > > > > > _______________________________________________ > > > 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 > --001a11339a6446161c05059220e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 as well. There is nothing of consequence that changed s= ince this discussion happened last time, so there is no possibility for the= decision.

_________= ____
Roman Shpount

On Thu, Oct 16, 2014 at 6:50 PM, Makaraju, M= aridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>= wrote:
+ 1

> -----Original Message-----
> From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Cavigioli, Chris
> Sent: Thursday, October 16, 2014 5:41 PM
> To: Bernard Aboba; Martin Thomson
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Plan for MTI video codec?
>
> I completely agree.=C2=A0 MTI is wasting time, given we know the indus= try is
> split between H.xxx and VPxxx ... and given we know that H.264/VP8 wil= l
> become H.265/VP9 rapidly ... we need to ensure WebRTC works with vario= us
> codecs and guide the industry towards VP8, H.264, VP9, H.265 (not some= other
> variant).=C2=A0 There will be some vendors who support both formats an= d some who
> don't.
> -chris
>
> -----Original Message-----
> From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Bernard Aboba
> Sent: Thursday, October 16, 2014 3:03 PM
> To: Martin Thomson
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Plan for MTI video codec?
>
> One thing we could do instead of wasting time on MTI is to actually ma= ke
> progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could=
> actually interoperate regardless of the codec.
>
>
>
> > On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >
> >> On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
> >> And that's because something substantive has changed, or = simply
> >> because wasting the WG time on this again is more entertainin= g than
> >> actually finishing a specification that can be independently<= br> > >> implemented by all browser vendors? (A specification that we = are
> >> nowhere near having, as far as I can tell)
> >
> > Personally, I've found the reprieve from this fight refreshin= g.=C2=A0 And
> > it would appear that we've made some real progress as a resul= t.=C2=A0 I'd
> > suggest that if we don't have new information, we continue to= spend
> > our time productively.=C2=A0 If we can't find topics to occup= y our meeting
> > agenda time, then maybe we can free an agenda slot.
> >
> > _______________________________________________
> > 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

--001a11339a6446161c05059220e2-- From nobody Fri Oct 17 02:39:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D79C1AC3AB for ; Fri, 17 Oct 2014 02:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7sICFkYFHlm for ; Fri, 17 Oct 2014 02:39:13 -0700 (PDT) Received: from relay.mailchannels.net (aso-006-i443.relay.mailchannels.net [23.91.64.124]) by ietfa.amsl.com (Postfix) with ESMTP id C5F131AC3AA for ; Fri, 17 Oct 2014 02:39:12 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id 88874100678 for ; Fri, 17 Oct 2014 09:39:10 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.216.27.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.3.1); Fri, 17 Oct 2014 09:39:11 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1413538750860:2198046507 X-MC-Ingress-Time: 1413538750753 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:62730 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xf404-0003f8-NZ for rtcweb@ietf.org; Fri, 17 Oct 2014 04:39:08 -0500 Message-ID: <5440E38F.9070809@jesup.org> Date: Fri, 17 Oct 2014 05:38:23 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> <543CD1CD.3000001@alvestrand.no> In-Reply-To: <543CD1CD.3000001@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3-nNbewDy1_vjVAOLIEoPdzXWdI Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 09:39:15 -0000 On 10/14/2014 3:33 AM, Harald Alvestrand wrote: > On 10/13/2014 07:02 PM, Wyss, Felix wrote: > >> They would only see it as a peer if it were a full B2B user agent. As an example, in VoIP the endpoints do not consider an SBC as a peer--yet it sits in the middle and may inspect the media passing through it. >> >> With respect to DCEP: If we already define a protocol for establishing the channels in-band, why not make ID selection and conflict resolution an explicit part of it? That certainly would beat the IMHO rather distasteful DTLS role hack. > When rethinking this, I've come to the conclusion that my original > conclusion (that there couldn't possibly be a point in preserving > channel numbers across a relay) was probably wrong. Please consider that > withdrawn. > > I now see a tradeoff between allowing such non-mapping boxes (operating > below the SCTP layer but above the DTLS layer in our model) and avoiding > additional complexity (either extending DCEP with glare resolution - > something it was designed to avoid needing - or requiring such boxes to > not use actpass). I'll note that not only does it have to sit between the SCTP and DTLS layers, but also it has to be the offerer to both sides as well. While certainly there are some use-cases for that, it's by no means the common case. WebRTC applications designed to work with such a midpoint may need to fall back on "external" negotiation, perhaps running a short sequence at opening time to decide who will get even and odd (assuming that both sides actually open channels dynamically). It means you may not be able to drop such a middlebox (and have it initiate offers to both sides) without a cooperative application (or one known to have a compatible usage patter) - but likely you need some level of known compatibility anyways, or more likely the entity deploying the middlebox also deploys or chooses the application - especially as we've explicitly said that signaling protocols and transmission (i.e. sending the offer, etc) is explicitly not defined by the WG, so the middlebox, in order to generate the offers to both sides *must* be in bed somehow with the applications - at least to where they all agree on signaling. > I agree that the DTLS hack is ugly. But glare resolution is ugly too. Quite so. We had glare resolution in earlier versions. It sucked and caused lots of problems, especially with 0-rtt opens. While DTLS role isn't wonderful, neither was anything else proposed. Offerer/answerer status has the same problem. An SDP parameter would allow a middlebox to specify to the endpoints compatible (complementary) values; however from a DataChannels perspective, this is almost the same as external negotiation if the middlebox and applications are 'matched'. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Fri Oct 17 04:31:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9271AC3E0 for ; Fri, 17 Oct 2014 04:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrGKl2DAI0_x for ; Fri, 17 Oct 2014 04:31:03 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A95C1AC3D9 for ; Fri, 17 Oct 2014 04:31:02 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 08299A1578D8C; Fri, 17 Oct 2014 11:30:58 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9HBUwnV020233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 13:30:58 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 13:30:58 +0200 From: "DRAGE, Keith (Keith)" To: Roman Shpount , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP6Yadl2Qsv7sEAECBFDAOBE1CspwzG5WAgAAJmQCAAAq1AIAAAsUAgAAA8wCAAPQ2oA== Date: Fri, 17 Oct 2014 11:30:58 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B261266@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <544035DE.8000606@matthew.at> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B261266FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fVwCn3dlzUYs0sXjJilb5Ulz_gg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 11:31:06 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B261266FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What I am seeing is a better awareness of APIs for accessing embedded codec= hardware in the client, and independently of any MTI codec discussion, I t= hink the codec document should address the existing of these, and how they = might be used. At least it should not ignore the issue entirely. But I do agree that I do not really want an MTI codec discussion (unless we= find a late night bar to do it in). Keith ________________________________ From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount Sent: 16 October 2014 23:54 To: Makaraju, Maridi Raju (Raju) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? +1 as well. There is nothing of consequence that changed since this discuss= ion happened last time, so there is no possibility for the decision. _____________ Roman Shpount On Thu, Oct 16, 2014 at 6:50 PM, Makaraju, Maridi Raju (Raju) > wrote: + 1 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cavigioli, Chris > Sent: Thursday, October 16, 2014 5:41 PM > To: Bernard Aboba; Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Plan for MTI video codec? > > I completely agree. MTI is wasting time, given we know the industry is > split between H.xxx and VPxxx ... and given we know that H.264/VP8 will > become H.265/VP9 rapidly ... we need to ensure WebRTC works with various > codecs and guide the industry towards VP8, H.264, VP9, H.265 (not some ot= her > variant). There will be some vendors who support both formats and some w= ho > don't. > -chris > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, October 16, 2014 3:03 PM > To: Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Plan for MTI video codec? > > One thing we could do instead of wasting time on MTI is to actually make > progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could > actually interoperate regardless of the codec. > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > > wrote: > > > >> On 16 October 2014 14:17, Matthew Kaufman > wrote: > >> And that's because something substantive has changed, or simply > >> because wasting the WG time on this again is more entertaining than > >> actually finishing a specification that can be independently > >> implemented by all browser vendors? (A specification that we are > >> nowhere near having, as far as I can tell) > > > > Personally, I've found the reprieve from this fight refreshing. And > > it would appear that we've made some real progress as a result. I'd > > suggest that if we don't have new information, we continue to spend > > our time productively. If we can't find topics to occupy our meeting > > agenda time, then maybe we can free an agenda slot. > > > > _______________________________________________ > > 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 --_000_949EF20990823C4C85C18D59AA11AD8B261266FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What I am seeing is a better awar= eness of APIs for accessing embedded codec hardware in the client, and inde= pendently of any MTI codec discussion, I think the codec document should address the existing of these, and how they migh= t be used. At least it should not ignore the issue entirely.<= /div>
 
But I do agree that I do not real= ly want an MTI codec discussion (unless we find a late night bar to do it i= n).
 
Keith

From: rtcweb [mailto:rtcweb-bounces= @ietf.org] On Behalf Of Roman Shpount
Sent: 16 October 2014 23:54
To: Makaraju, Maridi Raju (Raju)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan for MTI video codec?

+1 as well. There is nothing of consequence that chang= ed since this discussion happened last time, so there is no possibility for= the decision.

_____________
Roman Shpount

On Thu, Oct 16, 2014 at 6:50 PM, Makaraju, Marid= i Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
+ 1

> -----Original Message-----
> From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Cavigioli, Chris
> Sent: Thursday, October 16, 2014 5:41 PM
> To: Bernard Aboba; Martin Thomson
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Plan for MTI video codec?
>
> I completely agree.  MTI is wasting time, given we know the indus= try is
> split between H.xxx and VPxxx ... and given we know that H.264/VP8 wil= l
> become H.265/VP9 rapidly ... we need to ensure WebRTC works with vario= us
> codecs and guide the industry towards VP8, H.264, VP9, H.265 (not some= other
> variant).  There will be some vendors who support both formats an= d some who
> don't.
> -chris
>
> -----Original Message-----
> From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Bernard Aboba
> Sent: Thursday, October 16, 2014 3:03 PM
> To: Martin Thomson
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Plan for MTI video codec?
>
> One thing we could do instead of wasting time on MTI is to actually ma= ke
> progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could=
> actually interoperate regardless of the codec.
>
>
>
> > On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >
> >> On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
> >> And that's because something substantive has changed, or simp= ly
> >> because wasting the WG time on this again is more entertainin= g than
> >> actually finishing a specification that can be independently<= br> > >> implemented by all browser vendors? (A specification that we = are
> >> nowhere near having, as far as I can tell)
> >
> > Personally, I've found the reprieve from this fight refreshing.&n= bsp; And
> > it would appear that we've made some real progress as a result.&n= bsp; I'd
> > suggest that if we don't have new information, we continue to spe= nd
> > our time productively.  If we can't find topics to occupy ou= r meeting
> > agenda time, then maybe we can free an agenda slot.
> >
> > _______________________________________________
> > 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

--_000_949EF20990823C4C85C18D59AA11AD8B261266FR712WXCHMBA11zeu_-- From nobody Fri Oct 17 06:22:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A151ACDA7 for ; Fri, 17 Oct 2014 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h9u3wjUwPCP for ; Fri, 17 Oct 2014 06:22:08 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0531ACDBD for ; Fri, 17 Oct 2014 06:22:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 444D87C4994 for ; Fri, 17 Oct 2014 15:22:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rtmh9OSq3z5D for ; Fri, 17 Oct 2014 15:22:04 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:4ce8:48b8:b02b:3825]) by mork.alvestrand.no (Postfix) with ESMTPSA id C172B7C42C8 for ; Fri, 17 Oct 2014 15:22:04 +0200 (CEST) Message-ID: <544117FB.6050706@alvestrand.no> Date: Fri, 17 Oct 2014 15:22:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <544035DE.8000606@matthew.at> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uKcCYHupcETZyRsWDDCnIneA1RQ Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 13:22:14 -0000 On 10/17/2014 12:02 AM, Bernard Aboba wrote: > One thing we could do instead of wasting time on MTI is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually interoperate regardless of the codec. The big argument for an MTI is actually the one stated in -overview: It guards against interoperability failure. I would like to have an ecosystem where one can field a box, connect it to everything else, and run well for *some* level of "well" - and I would prefer that ecosystem to be one where it's possible to field the box without making prior arrangements with anyone about licenses. This argument hasn't changed one whit since last time we discussed it. And I don't see much movement on the specifics of the proposals either. We'll have to interoperate well with the codecs we field. So using some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't finished either. There's one sentence that needs to be removed.) I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer to re-discuss based on the knowledge that some significant players have actually changed their minds. At the moment, I don't see signs that any of the poll respondents have said "I have changed my mind". Harald > > > >> On Oct 16, 2014, at 2:28 PM, Martin Thomson wrote: >> >>> On 16 October 2014 14:17, Matthew Kaufman wrote: >>> And that's because something substantive has changed, or simply because >>> wasting the WG time on this again is more entertaining than actually >>> finishing a specification that can be independently implemented by all >>> browser vendors? (A specification that we are nowhere near having, as far as >>> I can tell) >> Personally, I've found the reprieve from this fight refreshing. And >> it would appear that we've made some real progress as a result. I'd >> suggest that if we don't have new information, we continue to spend >> our time productively. If we can't find topics to occupy our meeting >> agenda time, then maybe we can free an agenda slot. >> >> _______________________________________________ >> 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 nobody Fri Oct 17 06:25:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C7F1A1B7F for ; Fri, 17 Oct 2014 06:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGU7rPH_w99q for ; Fri, 17 Oct 2014 06:25:47 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 959201ACDBD for ; Fri, 17 Oct 2014 06:25:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 56FAD7C4994 for ; Fri, 17 Oct 2014 15:25:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP6iLQ8uKbUR for ; Fri, 17 Oct 2014 15:25:42 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:4ce8:48b8:b02b:3825]) by mork.alvestrand.no (Postfix) with ESMTPSA id 53F207C42C8 for ; Fri, 17 Oct 2014 15:25:42 +0200 (CEST) Message-ID: <544118D5.2080702@alvestrand.no> Date: Fri, 17 Oct 2014 15:25:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080706010007090109000504" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dbMiI8Kj1SGyqLXQsewmPFb-UFc Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 13:25:49 -0000 This is a multi-part message in MIME format. --------------080706010007090109000504 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/16/2014 07:10 PM, Ted Hardie wrote: > During this morning chairs call, we discussed the agenda for the > upcoming meeting. The two big items are JSEP and the video codec > discussion, and our current thought is to have the JSEP discussion on > Monday and the video codec discussion on Thursday. There are a number > of items we may need to discuss; if there are particular issues you > feel we need to cover, please send a message to the list with the > topic and the amount of time you feel you need. We have not had face to face discussion on draft-alvestrand-rtcweb-gateways (and not much discussion on the mailing list either). I'd like to have a review of that document on the agenda. Note: In my opinion, the chairs can choose to decide on whether the group should adopt the draft before, during or after the meeting, with or without calling for consensus of the WG. I would like to have the chairs say what they intend to do about this document. > > thanks, > > Ted, Cullen, Sean > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------080706010007090109000504 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/16/2014 07:10 PM, Ted Hardie wrote:
During this morning chairs call, we discussed the agenda for the upcoming meeting.  The two big items are JSEP and the video codec discussion, and our current thought is to have the JSEP discussion on Monday and the video codec discussion on Thursday.  There are a number of items we may need to discuss; if there are particular issues you feel we need to cover, please send a message to the list with the topic and the amount of time you feel you need.

We have not had face to face discussion on draft-alvestrand-rtcweb-gateways (and not much discussion on the mailing list either).

I'd like to have a review of that document on the agenda.

Note: In my opinion, the chairs can choose to decide on whether the group should adopt the draft before, during or after the meeting, with or without calling for consensus of the WG.

I would like to have the chairs say what they intend to do about this document.


thanks,

Ted, Cullen, Sean


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

--------------080706010007090109000504-- From nobody Fri Oct 17 13:00:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE4C1A6FBB for ; Fri, 17 Oct 2014 13:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm9ajlKz7EPg for ; Fri, 17 Oct 2014 13:00:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0063.outbound.protection.outlook.com [65.55.169.63]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB681A01FA for ; Fri, 17 Oct 2014 13:00:19 -0700 (PDT) Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 20:00:17 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1054.004; Fri, 17 Oct 2014 20:00:17 +0000 From: "Wyss, Felix" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYIAADzmAgAAmfQCAAFWsAIAAG4cggAEmdgCAADW+gIAAINaAgAAXDgCAAA+BgIAAIqQAgABN64CAAPELcIABF92AgATZ34CAAJFUwA== Date: Fri, 17 Oct 2014 20:00:17 +0000 Message-ID: References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> <543CD1CD.3000001@alvestrand.no> <5440E38F.9070809@jesup.org> In-Reply-To: <5440E38F.9070809@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.147.12.61] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1578; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(164054003)(51704005)(199003)(76576001)(80022003)(99286002)(95666004)(46102003)(122556002)(106116001)(85306004)(93886004)(40100003)(106356001)(74316001)(33646002)(107886001)(77096002)(99396003)(107046002)(120916001)(101416001)(230783001)(86362001)(76482002)(108616004)(54356999)(92566001)(76176999)(50986999)(4396001)(85852003)(87936001)(31966008)(2656002)(105586002)(97736003)(21056001)(20776003)(66066001)(2501002)(64706001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1578; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZkuzkGIvVbxtSsBFQ-zPR-yYHF8 Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 20:00:22 -0000 > > I now see a tradeoff between allowing such non-mapping boxes > > (operating below the SCTP layer but above the DTLS layer in our model) > > and avoiding additional complexity (either extending DCEP with glare > > resolution - something it was designed to avoid needing - or requiring > > such boxes to not use actpass). >=20 > I'll note that not only does it have to sit between the SCTP and DTLS lay= ers, > but also it has to be the offerer to both sides as well.=20 This is a problem even if the middlebox is the answerer on one side and the= offerer on the other (relay). As offerer it cannot control what role it w= ill play without violating RFC#5763. As Indicated in my response to Harald= from the 15th, I do not believe allowing the offerer to offer anything but= actpass to be a desirable approach. =20 > While certainly there are some use-cases for that, it's by no means the c= ommon case. =20 > WebRTC applications designed to work with such a midpoint may need to fal= l back on > "external" negotiation, perhaps running a short sequence at opening time = to > decide who will get even and odd (assuming that both sides actually open > channels dynamically). > It means you may not be able to drop such a middlebox (and have it initia= te > offers to both sides) without a cooperative application (or one known to > have a compatible usage patter) - but likely you need some level of known > compatibility anyways, or more likely the entity deploying the middlebox = also > deploys or chooses the application - especially as we've explicitly said = that > signaling protocols and transmission (i.e. sending the offer, etc) is exp= licitly > not defined by the WG, so the middlebox, in order to generate the offers = to > both sides > *must* be in bed somehow with the applications - at least to where they a= ll > agree on signaling. Well, then why not leave the ID generation and conflict resolution complete= ly up to the application? That takes the DTLS role hack out of the pictur= e too. Of course, leaving it to the application how it determines the ID r= isks that poorly written applications just pick it at random or some other = criteria and don't worry about collisions ("well, it worked in my tests"). = =20 > > I agree that the DTLS hack is ugly. But glare resolution is ugly too. >=20 > Quite so. We had glare resolution in earlier versions. It sucked and cau= sed > lots of problems, especially with 0-rtt opens. >=20 > While DTLS role isn't wonderful, neither was anything else proposed. > Offerer/answerer status has the same problem. =20 Even the offerer/answerer role would be better than the DTLS role. At leas= t that would work in the case where the middlebox relays the offer and answ= er. I think that's still too limiting as I'd rather allow the middlebox to= be offerer on both sides, but I'll take it over the DTLS hack any day :-) > An SDP parameter would > allow a middlebox to specify to the endpoints compatible (complementary) > values; however from a DataChannels perspective, this is almost the same = as > external negotiation if the middlebox and applications are 'matched'. If in-band negotiation and collision resolution is not an option, adding an= SDP attribute would be my second choice. If it's not present, use offerer= /answerer role.=20 Thanks, --Felix From nobody Fri Oct 17 15:49:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A76D1A872E for ; Fri, 17 Oct 2014 15:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2ClVr2wa7rj for ; Fri, 17 Oct 2014 15:49:23 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255441A872C for ; Fri, 17 Oct 2014 15:49:23 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id id10so1310138vcb.34 for ; Fri, 17 Oct 2014 15:49:22 -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; bh=fD2yDl6wDDEw046/3EeUZmHSEDOEzAGsgYq8phXPh6Y=; b=cSrlmqN4pEQ8zbrzu4ZK5iMTlT2Nj39TDgCsQjTAq5exBCu55hRFLCbHuWI9cDBbkh ahbM5gNe19Ro2sv5NzhyUdaCo/G9N6CCEXPcr4Wi0nHYzdbtz/6f3Peks7rC+DBitKEZ 5igwciqO+Pd3y5PbDUe8t4dxF+C01ACJqWr3/0wdPSXaXrpnagLkbnS6QtkbNwj+ZqqB +SxnEUdD+EUfW2Ssoa2giLy8B7qySZoDlDKKvIrmpNr4F7l5TL4pZA6tRJka5iPRLbSu UE3+neP/4lSfKI4tRpfJHyVyMNY863nrHwqsxFvWurWMhOK093lfvlvFcTBOiHtgiO6v AtcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fD2yDl6wDDEw046/3EeUZmHSEDOEzAGsgYq8phXPh6Y=; b=HJpUi13FjTcefqZ3dkQMn7XS1ydZbYHPHMvXU5+V3NOq2Ny1cPo/veC81ahLGqsk3F MO8blbJW5r4t4yAK3Y5U2Orui+PuQR8VV5do60W2Tu11Rz9g/sJj4b+Ex0bw0fAC+ugF 53D3FYHQqm8R4L4BYeRdwtevT8aD5Ws2Zk/2nA8MkuWtSKvHdN7aLyblwCtD5TXC7g1a 7sb+AzSKZfedyS1/OLkbQRdmQmiqe4ADYzsIAlZJHjfN2hpvB7WlmpjtEY4+sQEtTfhr CBaUKqw21Koyq3zYBrJhMPE43iyX0/49Xy2JOadzAG832mmA06ZT8xE7lHJJojbGSq4L sJdg== X-Gm-Message-State: ALoCoQlzbTwtoCKPwey5U6pVdY5yiDrOE37HeniI0feLZlkPbBz3pfVMwXi7pam171FDiWViBUum X-Received: by 10.52.233.164 with SMTP id tx4mr2609704vdc.65.1413586162245; Fri, 17 Oct 2014 15:49:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Fri, 17 Oct 2014 15:49:02 -0700 (PDT) In-Reply-To: <544118D5.2080702@alvestrand.no> References: <544118D5.2080702@alvestrand.no> From: Justin Uberti Date: Fri, 17 Oct 2014 15:49:02 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e011849c40fc0170505a62de7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/b_vNkHGbNDZMGlVZkekPNXkU9io Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 22:49:24 -0000 --089e011849c40fc0170505a62de7 Content-Type: text/plain; charset=UTF-8 I would like to discuss enterprise WebRTC proxies, a previously unaddressed requirement which now has a proposal in https://tools.ietf.org/html/draft-schwartz-rtcweb-return-03 On Fri, Oct 17, 2014 at 6:25 AM, Harald Alvestrand wrote: > On 10/16/2014 07:10 PM, Ted Hardie wrote: > > During this morning chairs call, we discussed the agenda for the > upcoming meeting. The two big items are JSEP and the video codec > discussion, and our current thought is to have the JSEP discussion on > Monday and the video codec discussion on Thursday. There are a number of > items we may need to discuss; if there are particular issues you feel we > need to cover, please send a message to the list with the topic and the > amount of time you feel you need. > > > We have not had face to face discussion on > draft-alvestrand-rtcweb-gateways (and not much discussion on the mailing > list either). > > I'd like to have a review of that document on the agenda. > > Note: In my opinion, the chairs can choose to decide on whether the group > should adopt the draft before, during or after the meeting, with or without > calling for consensus of the WG. > > I would like to have the chairs say what they intend to do about this > document. > > > thanks, > > Ted, Cullen, Sean > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e011849c40fc0170505a62de7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to discuss enterprise WebRTC proxies, a previ= ously unaddressed requirement which now has a proposal in

On Fri, Oct 17, 2014 at 6:2= 5 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
=
=20 =20 =20
On 10/16/2014 07:10 PM, Ted Hardie wrote:
During this morning chairs call, we discussed the agenda for the upcoming meeting.=C2=A0 The two big items are JSEP and the video codec discussion, and our current thought is to have the JSEP discussion on Monday and the video codec discussion on Thursday.=C2=A0 There are a number of items we may need to discus= s; if there are particular issues you feel we need to cover, please send a message to the list with the topic and the amount of time you feel you need.

 We have not had face to face discussion on draft-alvestrand-rtcweb-gateways (and not much discussion on the mailing list either).

I'd like to have a review of that document on the agenda.

Note: In my opinion, the chairs can choose to decide on whether the group should adopt the draft before, during or after the meeting, with or without calling for consensus of the WG.

I would like to have the chairs say what they intend to do about this document.


thanks,

Ted, Cullen, Sean


_______________________________________________
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


--089e011849c40fc0170505a62de7-- From nobody Sat Oct 18 11:41:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279F81A00F9 for ; Sat, 18 Oct 2014 11:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwxFCDuFOIUL for ; Sat, 18 Oct 2014 11:41:11 -0700 (PDT) Received: from relay.mailchannels.net (si-002-i53.relay.mailchannels.net [184.154.112.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1901A00FD for ; Sat, 18 Oct 2014 11:41:10 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id 0CD4C120148 for ; Sat, 18 Oct 2014 18:41:07 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.251.53.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.3.1); Sat, 18 Oct 2014 18:41:08 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1413657668254:1760815717 X-MC-Ingress-Time: 1413657668254 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:56144 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XfYw6-0008rt-Sp for rtcweb@ietf.org; Sat, 18 Oct 2014 13:41:06 -0500 Message-ID: <5442B41D.6040307@jesup.org> Date: Sat, 18 Oct 2014 14:40:29 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> <543CD1CD.3000001@alvestrand.no> <5440E38F.9070809@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YtRfvq1Sr1KHc4Fb5-hKn3pWwaM Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 18:41:13 -0000 On 10/17/2014 4:00 PM, Wyss, Felix wrote: >>> I now see a tradeoff between allowing such non-mapping boxes >>> (operating below the SCTP layer but above the DTLS layer in our model) >>> and avoiding additional complexity (either extending DCEP with glare >>> resolution - something it was designed to avoid needing - or requiring >>> such boxes to not use actpass). >> I'll note that not only does it have to sit between the SCTP and DTLS layers, >> but also it has to be the offerer to both sides as well. So if we use SDP, the issues become one of ensuring the two sides always have different values. For direct calls, no problem (offerer sets mine=x, answerer sets mine=!x) For direct intermediated calls, the same (offer is just forwarded) For start-in-the-middle calls (3pcc) the middlebox sends offers to both sides, but can use complimentary values: offer->A mine=x, offer->B mine=!x (makes assumptions about how A and B will answer! & likely demands use of TURN server or media gateway) or offer->A mine=x, A->answer mine=!x, "offer"->B mine=!x, B->answer mine=x (and then the middlebox will start a renegotiation if for some reason B's answer is incompatible with A's response). May require some careful ICE candidate handling to avoid TURN. Note: I hate this sort of setup in SDP; it almost guarantees issues when you don't have tightly-coupled endpoints and thus know how they'll respond to the SDP. Note that in SIP-land-style you'd generally (always?) do it this way to avoid re-negotiation and avoid the tight coupling: offer->A with no SDP; A->"answer" (really createOffer()), offer->B, B->answer, answer->A (In SIP this would be OFFER->A (null SDP), A->200 OK(offer-SDP), OFFER->B(offer-SDP), B->200 OK (answer-SDP), ACK->A (answer-SDP), ACK->B (null) Note here that both sides agree who offered and answered, unlike the above, AND I believe that DTLS role use would work. > This is a problem even if the middlebox is the answerer on one side and the offerer on the other (relay). As offerer it cannot control what role it will play without violating RFC#5763. As Indicated in my response to Harald from the 15th, I do not believe allowing the offerer to offer anything but actpass to be a desirable approach. Per above, if it's simply asking the application for an offer, then forwarding it, there's no issue: the offer is a true offer, you never have to "convert" an SDP offer into an answer or vice versa, and the offer will be actpass and roles will be consistent (assuming the middlebox isn't trying to intercept/sniff the decrypted DataChannel data). So, if the middle box uses sip-style "empty offers" (ask the app to make an offer), then I think there are no issues with DTLS role. If it tries to avoid the 3-way handshake style, or work with apps that don't understand it then there'd be an issue (but in webrtc signaling isn't specified, so the middlebox MUST be designed to be compatible with the signaling used by the apps). Also, if the middlebox acts as an "answerer-in-the-middle", DTLS roles should work: A->middlebox offer, B->middlebox offer, middlebox->A answer, middlebox->B answer (where the answers are derived from the offer on the other side). This again requires that the two Offers be safely transformable by the middlebox into answers without a renegotiation. The middlebox would select the roles in the answers to be complimentary. >> While certainly there are some use-cases for that, it's by no means the common case. >> WebRTC applications designed to work with such a midpoint may need to fall back on >> "external" negotiation, perhaps running a short sequence at opening time to >> decide who will get even and odd (assuming that both sides actually open >> channels dynamically). >> It means you may not be able to drop such a middlebox (and have it initiate >> offers to both sides) without a cooperative application (or one known to >> have a compatible usage patter) - but likely you need some level of known >> compatibility anyways, or more likely the entity deploying the middlebox also >> deploys or chooses the application - especially as we've explicitly said that >> signaling protocols and transmission (i.e. sending the offer, etc) is explicitly >> not defined by the WG, so the middlebox, in order to generate the offers to >> both sides >> *must* be in bed somehow with the applications - at least to where they all >> agree on signaling. > Well, then why not leave the ID generation and conflict resolution completely up to the application? That takes the DTLS role hack out of the picture too. Of course, leaving it to the application how it determines the ID risks that poorly written applications just pick it at random or some other criteria and don't worry about collisions ("well, it worked in my tests"). As per above, an application can *always* do that, it never has to use the DTLS-role-reliant allocations. Webrtc doesn't specify the signaling side; any middlebox must agree with the apps on signaling, and thus you can put requirements on how that interaction works. Inserting a middlebox into existing application channels that were not designed for a middlebox at most requires you to allow the application to be told to generate an offer, OR for the application to use it's own generation/conflict resolution. What is not possible is to insert a middlebox between arbitrary WebRTC apps that are not designed with that in mind, AND to try to initiate calls from the "middle" (without the SDP solution). However, initiation from the middle in that way is fraught with other issues and need to renegotiate after the first pass anyways. >>> I agree that the DTLS hack is ugly. But glare resolution is ugly too. >> Quite so. We had glare resolution in earlier versions. It sucked and caused >> lots of problems, especially with 0-rtt opens. >> >> While DTLS role isn't wonderful, neither was anything else proposed. >> Offerer/answerer status has the same problem. > Even the offerer/answerer role would be better than the DTLS role. At least that would work in the case where the middlebox relays the offer and answer. I think that's still too limiting as I'd rather allow the middlebox to be offerer on both sides, but I'll take it over the DTLS hack any day :-) I disagree that role won't work if the middlebox is just forwarding offers and answers - that's what every WebRTC signaling server is doing today. However, as I think you implied, you're also terminating DTLS but forwarding SCTP (and media). This a) implies packet-relay; b) implicit decryption of all media at the server (NOTE this is a security/privacy/MITM issue). Still, if A->middlebox (offer) is actpass, and middlebox->B (offer) is actpass (and they would be), then B chooses the role, and then when forwarding the answer to A the middlebox can choose the same role B did. So I still don't see a problem here.... Also, assuming some bits of my analysis are incorrect, or there are edge cases we care about we don't handle (the non-SIP-like start-in-middle case), then (and only then) as a working group, we need to decide if this is a usecase we support. Obviously B2BUA's (which this more-or-less is) are always possible, at varying levels of ease. The question (partly) is should the protocol be designed to ease the use of a B2BUA with datachannels *assuming* it doesn't work per above. >> An SDP parameter would >> allow a middlebox to specify to the endpoints compatible (complementary) >> values; however from a DataChannels perspective, this is almost the same as >> external negotiation if the middlebox and applications are 'matched'. > If in-band negotiation and collision resolution is not an option, adding an SDP attribute would be my second choice. If it's not present, use offerer/answerer role. If we *cannot* safely use DTLS role for middlebox cases, and care, then we should allow SDP to override the DTLS role (not use the SDP offer state as the base). If an offerer doesn't specify even/odd in the SDP, but the answer does specify, then the offerer must use the SDP of the answerer to select even/odd (i.e. SDP overrides role). -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Sat Oct 18 14:08:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0F81A1A70 for ; Sat, 18 Oct 2014 14:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIQHYC_nRIAj for ; Sat, 18 Oct 2014 14:08:04 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E445B1A1A6E for ; Sat, 18 Oct 2014 14:08:03 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id vb8so2188610obc.17 for ; Sat, 18 Oct 2014 14:08: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=JV8ryEV4SIkxCXmighrXGv5Jx1wTMytj1T3SL7sbTMA=; b=ubWlEg3iOA2v0Vx9HBV7BRftlHdPHjJkAxE0sQoOS2Od9anEa3d2v8skXjLFUAWWGI npZyN2Muua+OnueLaPMqZ1bmpc+aBfwRnYt0ZRDHAbUoB1ZShdJpdFroWBvJ26B2l58l WpExyxa1yL0JmU7WLP0uKRrhy2+U9VYlIieUWE1oY/es6z4RA/Gmz0aZJO/M0gbYjH6M T7OpoNi4JX6bOQnmcDo22FdaXDc7eSxIICzzIBUYzuyBvMeHS4+/jDBoK9dahFlEeKV4 0FTGIuxNQPBeDDY9LXZ0cu9ZJL8NP+KedxajRfPxW3f+kfxrr2TRLCCQWeqqius3ZvRb 0rlA== MIME-Version: 1.0 X-Received: by 10.202.206.144 with SMTP id e138mr3257009oig.64.1413666483270; Sat, 18 Oct 2014 14:08:03 -0700 (PDT) Received: by 10.202.66.5 with HTTP; Sat, 18 Oct 2014 14:08:03 -0700 (PDT) In-Reply-To: <544117FB.6050706@alvestrand.no> References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Date: Sun, 19 Oct 2014 05:08:03 +0800 Message-ID: From: Alexandre GOUAILLARD To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a113ad9f090fbc80505b8e028 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fhm4bBh6gkhrpl8yvpkp4XkchwY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 21:08:06 -0000 --001a113ad9f090fbc80505b8e028 Content-Type: text/plain; charset=UTF-8 +1 to not having MTI codec discussion unless some progress has been made on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that there was no change on the members position. On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand wrote: > On 10/17/2014 12:02 AM, Bernard Aboba wrote: > >> One thing we could do instead of wasting time on MTI is to actually make >> progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >> actually interoperate regardless of the codec. >> > > The big argument for an MTI is actually the one stated in -overview: It > guards against interoperability failure. > > I would like to have an ecosystem where one can field a box, connect it to > everything else, and run well for *some* level of "well" - and I would > prefer that ecosystem to be one where it's possible to field the box > without making prior arrangements with anyone about licenses. > > This argument hasn't changed one whit since last time we discussed it. And > I don't see much movement on the specifics of the proposals either. > > We'll have to interoperate well with the codecs we field. So using some > time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't > finished either. There's one sentence that needs to be removed.) > > I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd > prefer to re-discuss based on the knowledge that some significant players > have actually changed their minds. > > At the moment, I don't see signs that any of the poll respondents have > said "I have changed my mind". > > Harald > > > > >> >> >> On Oct 16, 2014, at 2:28 PM, Martin Thomson >>> wrote: >>> >>> On 16 October 2014 14:17, Matthew Kaufman wrote: >>>> And that's because something substantive has changed, or simply because >>>> wasting the WG time on this again is more entertaining than actually >>>> finishing a specification that can be independently implemented by all >>>> browser vendors? (A specification that we are nowhere near having, as >>>> far as >>>> I can tell) >>>> >>> Personally, I've found the reprieve from this fight refreshing. And >>> it would appear that we've made some real progress as a result. I'd >>> suggest that if we don't have new information, we continue to spend >>> our time productively. If we can't find topics to occupy our meeting >>> agenda time, then maybe we can free an agenda slot. >>> >>> _______________________________________________ >>> 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 > -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - --001a113ad9f090fbc80505b8e028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to not having MTI codec discussion unless some progress= has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing haral= d's =C2=A0feeling that there was no change on the members position.=C2= =A0

On Fri, = Oct 17, 2014 at 9:22 PM, Harald Alvestrand <harald@alvestrand.no>= ; wrote:
On 10/17= /2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 A= nd
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------

--001a113ad9f090fbc80505b8e028-- From nobody Sat Oct 18 14:25:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CA11A1AA0 for ; Sat, 18 Oct 2014 14:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3NgaOO4MRGk for ; Sat, 18 Oct 2014 14:25:16 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07E1A1A8A for ; Sat, 18 Oct 2014 14:25:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3263D7C4E74; Sat, 18 Oct 2014 23:25:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNdOUVP5utF6; Sat, 18 Oct 2014 23:25:05 +0200 (CEST) Received: from [172.30.42.84] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by mork.alvestrand.no (Postfix) with ESMTPSA id EB7BF7C4C1E; Sat, 18 Oct 2014 23:25:04 +0200 (CEST) Message-ID: <5442DAAF.6020304@alvestrand.no> Date: Sat, 18 Oct 2014 23:25:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Alexandre GOUAILLARD References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kztjj9jAYV9R_InA21YWK1rnc88 Cc: "rtcweb@ietf.org" Subject: [rtcweb] VP8 in ISO (Re: Plan for MTI video codec?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 21:25:18 -0000 Changing the subject line, since this is information that more people may be interested in having called out clearly: On 10/18/2014 11:08 PM, Alexandre GOUAILLARD wrote: > +1 to not having MTI codec discussion unless some progress has been > made on VP8 at MPEG. Any news on that? The VCB spec (VP8 in ISO) is in DIS ballot, and the ballot closes in January. ISO processes are complex, and I don't always understand them, but if the ballot results are positive, the standard should be approved. So far, we have not seen any official feedback, but all the unofficial feedback I've seen has been more or less editorial in nature. There are no technical changes that would cause any issues in compatibility between VP8 and VCB. From nobody Sat Oct 18 18:34:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF321A0143 for ; Sat, 18 Oct 2014 18:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7dcil5xpSoK for ; Sat, 18 Oct 2014 18:34:14 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B66B1A00CF for ; Sat, 18 Oct 2014 18:34:14 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id wm4so2290063obc.40 for ; Sat, 18 Oct 2014 18:34:13 -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=2xiqJIM+vZy8umDkGq8mo1s30NemYDg4TRGh7brKPGE=; b=cfhORu0P1HXvLnJw7FBFXC1zV9+5ZEaYYisGefMBnsIGCL4oVCH2rGkyeAxaADKgKP EqbGu9BJ3BbgvhUoSJeSFAtcjmslBmUh46a/dZ/8k6k8WqI2UzQXYkeGePMpaKaCYKH/ 3XeDBK3bV37adPQpCliyX8IHrIoHHBdxkyerPcgK6iQSbYAKJpfLnyPxVGM3sWpPipvZ wNZz76BrnlrknDaHWGhM35re/ET0j/G6OhBjbM2YAOemVaPA6d8LAnm5aa7IjF/oWhN6 axio95azwZpIzQVipVyRMPUTHKUCZun/2MsXXHnz3dDOKiyzBFsVrXiOOWTiiXdLth2P 4xow== MIME-Version: 1.0 X-Received: by 10.182.248.138 with SMTP id ym10mr14774388obc.5.1413682453487; Sat, 18 Oct 2014 18:34:13 -0700 (PDT) Received: by 10.202.66.5 with HTTP; Sat, 18 Oct 2014 18:34:13 -0700 (PDT) In-Reply-To: <5442DAAF.6020304@alvestrand.no> References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <5442DAAF.6020304@alvestrand.no> Date: Sun, 19 Oct 2014 09:34:13 +0800 Message-ID: From: Alexandre GOUAILLARD To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c29d5e77256c0505bc9866 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VVLEtBQ0_gX7YDhJNeZzoEnElT8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] VP8 in ISO (Re: Plan for MTI video codec?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 01:34:16 -0000 --001a11c29d5e77256c0505bc9866 Content-Type: text/plain; charset=UTF-8 Thanks harald for the update. I'm tempted to say that this is the only event I can think off, based on the results of the previous pool, that would motivate some from changing their mind. Hence putting the MTI discussion back on the table before any progress on VP8 in IOS is, IMHO, useless. Alex. On Sun, Oct 19, 2014 at 5:25 AM, Harald Alvestrand wrote: > > Changing the subject line, since this is information that more people > may be interested in having called out clearly: > > On 10/18/2014 11:08 PM, Alexandre GOUAILLARD wrote: > > +1 to not having MTI codec discussion unless some progress has been > > made on VP8 at MPEG. Any news on that? > > The VCB spec (VP8 in ISO) is in DIS ballot, and the ballot closes in > January. > ISO processes are complex, and I don't always understand them, but if > the ballot results are positive, the standard should be approved. > > So far, we have not seen any official feedback, but all the unofficial > feedback I've seen has been more or less editorial in nature. > > There are no technical changes that would cause any issues in > compatibility between VP8 and VCB. > > -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - --001a11c29d5e77256c0505bc9866 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks harald for the update.

I'm t= empted to say that this is the only event I can think off, based on the res= ults of the previous pool, that would motivate some from changing their min= d. Hence putting the MTI discussion back on the table before any progress o= n VP8 in IOS is, IMHO, useless.=C2=A0

Alex.
<= /div>

On Sun, Oct = 19, 2014 at 5:25 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

Changing the subject line, since this is information that more people
may be interested in having called out clearly:

On 10/18/2014 11:08 PM, Alexandre GOUAILLARD wrote:
> +1 to not having MTI codec discussion unless some progress has been > made on VP8 at MPEG. Any news on that?

The VCB spec (VP8 in ISO) is in DIS ballot, and the ballot closes in
January.
ISO processes are complex, and I don't always understand them, but if the ballot results are positive, the standard should be approved.

So far, we have not seen any official feedback, but all the unofficial
feedback I've seen has been more or less editorial in nature.

There are no technical changes that would cause any issues in
compatibility between VP8 and VCB.




--
Alex. Gouaillard, PhD, PhD, MBA
----------------------------------= --------------------------------------------------
CTO - Temasys = Communications, S'pore / Mountain View
President - CoSMo Soft= ware, Cambridge, MA
---------------------------------------------= ---------------------------------------
--001a11c29d5e77256c0505bc9866-- From nobody Sun Oct 19 08:15:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9FD1A1AF1 for ; Sun, 19 Oct 2014 08:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkpGA7PVUFnn for ; Sun, 19 Oct 2014 08:14:59 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235721A1AE1 for ; Sun, 19 Oct 2014 08:14:59 -0700 (PDT) Received: from mail-wg0-f43.google.com ([74.125.82.43]:39667) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XfsBv-0003pm-JX for rtcweb@ietf.org; Sun, 19 Oct 2014 11:14:55 -0400 Received: by mail-wg0-f43.google.com with SMTP id m15so3824909wgh.14 for ; Sun, 19 Oct 2014 08:14:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.2.129 with SMTP id 1mr26600812wju.12.1413731682293; Sun, 19 Oct 2014 08:14:42 -0700 (PDT) Received: by 10.194.120.66 with HTTP; Sun, 19 Oct 2014 08:14:42 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Date: Sun, 19 Oct 2014 11:14:42 -0400 Message-ID: From: Jonathan Rosenberg To: Alexandre GOUAILLARD Content-Type: multipart/alternative; boundary=047d7b343d30bb22180505c80eab X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GyZU3aJMTrtorMhzTEEG-JNQ4ok Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 15:15:01 -0000 --047d7b343d30bb22180505c80eab Content-Type: text/plain; charset=UTF-8 I'm in favor of taking another run at this. The working group has repeatedly said that an MTI codec is something we need to produce. And its one of the issues holding up wider adoption of the technology (not the only one for sure). And things have changed since the last meeting, a year ago now (November in Vancouver). Cisco's open264 plugin shipped and now just recently is integrated into Firefox. iOS8 shipped with APIs for H264. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth finding out. On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD wrote: > +1 to not having MTI codec discussion unless some progress has been made > on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that there > was no change on the members position. > > On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: > >> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >> >>> One thing we could do instead of wasting time on MTI is to actually make >>> progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >>> actually interoperate regardless of the codec. >>> >> >> The big argument for an MTI is actually the one stated in -overview: It >> guards against interoperability failure. >> >> I would like to have an ecosystem where one can field a box, connect it >> to everything else, and run well for *some* level of "well" - and I would >> prefer that ecosystem to be one where it's possible to field the box >> without making prior arrangements with anyone about licenses. >> >> This argument hasn't changed one whit since last time we discussed it. >> And I don't see much movement on the specifics of the proposals either. >> >> We'll have to interoperate well with the codecs we field. So using some >> time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't >> finished either. There's one sentence that needs to be removed.) >> >> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >> prefer to re-discuss based on the knowledge that some significant players >> have actually changed their minds. >> >> At the moment, I don't see signs that any of the poll respondents have >> said "I have changed my mind". >> >> Harald >> >> >> >> >>> >>> >>> On Oct 16, 2014, at 2:28 PM, Martin Thomson >>>> wrote: >>>> >>>> On 16 October 2014 14:17, Matthew Kaufman wrote: >>>>> And that's because something substantive has changed, or simply because >>>>> wasting the WG time on this again is more entertaining than actually >>>>> finishing a specification that can be independently implemented by all >>>>> browser vendors? (A specification that we are nowhere near having, as >>>>> far as >>>>> I can tell) >>>>> >>>> Personally, I've found the reprieve from this fight refreshing. And >>>> it would appear that we've made some real progress as a result. I'd >>>> suggest that if we don't have new information, we continue to spend >>>> our time productively. If we can't find topics to occupy our meeting >>>> agenda time, then maybe we can free an agenda slot. >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > Alex. Gouaillard, PhD, PhD, MBA > > ------------------------------------------------------------------------------------ > CTO - Temasys Communications, S'pore / Mountain View > President - CoSMo Software, Cambridge, MA > > ------------------------------------------------------------------------------------ > sg.linkedin.com/agouaillard > > - > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --047d7b343d30bb22180505c80eab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm in favor of taking another run at this.

The working group has repeatedly said that an MTI codec is somethi= ng we need to produce. And its one of the issues holding up wider adoption = of the technology (not the only one for sure).

And= things have changed since the last meeting, a year ago now (November in Va= ncouver). Cisco's open264 plugin shipped and now just recently is integ= rated into Firefox. iOS8 shipped with APIs for H264. There are other things= worth noting. Will this change the minds of everyone? Surely not. Will it = sway enough for us to achieve rough consensus? Maybe. IMHO - worth finding = out.

O= n Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <= agouaillard@gmai= l.com> wrote:
+1 to not having MTI codec discussion unless some progress has been mad= e on VP8 at MPEG.=C2=A0Any news on that? I'm sharing harald's =C2= =A0feeling that there was no change on the members position.=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <= ;harald@alvestran= d.no> wrote:
On 10/17= /2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 A= nd
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



<= /div>--
Alex. Gouaillard, PhD, PhD, MBA
--------------------------------------= ----------------------------------------------
CTO - Temasys Comm= unications, S'pore / Mountain View
President - CoSMo Software= , Cambridge, MA
-------------------------------------------------= -----------------------------------


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




--
--047d7b343d30bb22180505c80eab-- From nobody Sun Oct 19 08:43:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D07F1A1B48 for ; Sun, 19 Oct 2014 08:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVFNbt7PqVXM for ; Sun, 19 Oct 2014 08:43:52 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701BD1A1B45 for ; Sun, 19 Oct 2014 08:43:52 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so3842963wgh.5 for ; Sun, 19 Oct 2014 08:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RbJ1Ka/0cFysFBZFhz1oKXN7plzob27YiZKgG8ahBds=; b=UeV3tBAqPRlBE5G6C2sLfTp0Kzeq/BEMwNLbQ8V8vlCYduj+oleL8i2oVDCSJmuo3M PfXeLUye0ApPSVqUWYI/bPN4i5lK+nN7hDJ48n+34Szr0hvQ+7Y/ysSC2OdSF/RgzeqO Jdg/sdUm4pEpBhJcDyuF6Ovum1nrN3y4e5DbP45NlriftQydZneiPPw6+CWkDl26Z8ak YmBkeE189Z5vC619sSeGo4AIbgk2A3cT4g9WtkQcgTQ/s7jKD5aPmprJujVwCCeYjrmC pEv42Ap83l8JO0HgpIGCNjAw1rVFwB7x4pxuL7R0+XT+/efe7QAYjC7FhVlX1dXgk3Qg 5Q4Q== X-Received: by 10.194.239.10 with SMTP id vo10mr26249615wjc.29.1413733430988; Sun, 19 Oct 2014 08:43:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.134.196 with HTTP; Sun, 19 Oct 2014 08:43:30 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> From: Bernard Aboba Date: Sun, 19 Oct 2014 08:43:30 -0700 Message-ID: To: Jonathan Rosenberg Content-Type: multipart/alternative; boundary=001a11c28eccf61aaa0505c8767a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/b_x8wQhQAWuv4ZuLy5EZF5FQRjU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 15:43:55 -0000 --001a11c28eccf61aaa0505c8767a Content-Type: text/plain; charset=UTF-8 "And its one of the issues holding up wider adoption of the technology" [BA] Specifying an MTI encoder/decoder is not sufficient for interoperability. It is also necessary to specify the transport in enough detail to allow independent implementations that interoperate well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienced. We made the mistake of having an MTI discussion previously with not enough details on that subject, particularly with respect to H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. So if we are to have the discussion again, it should occur in the context of detailed specifications and interoperability reports. On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg wrote: > I'm in favor of taking another run at this. > > The working group has repeatedly said that an MTI codec is something we > need to produce. And its one of the issues holding up wider adoption of the > technology (not the only one for sure). > > And things have changed since the last meeting, a year ago now (November > in Vancouver). Cisco's open264 plugin shipped and now just recently is > integrated into Firefox. iOS8 shipped with APIs for H264. There are other > things worth noting. Will this change the minds of everyone? Surely not. > Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth > finding out. > > On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < > agouaillard@gmail.com> wrote: > >> +1 to not having MTI codec discussion unless some progress has been made >> on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that there >> was no change on the members position. >> >> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand >> wrote: >> >>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>> >>>> One thing we could do instead of wasting time on MTI is to actually >>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >>>> actually interoperate regardless of the codec. >>>> >>> >>> The big argument for an MTI is actually the one stated in -overview: It >>> guards against interoperability failure. >>> >>> I would like to have an ecosystem where one can field a box, connect it >>> to everything else, and run well for *some* level of "well" - and I would >>> prefer that ecosystem to be one where it's possible to field the box >>> without making prior arrangements with anyone about licenses. >>> >>> This argument hasn't changed one whit since last time we discussed it. >>> And I don't see much movement on the specifics of the proposals either. >>> >>> We'll have to interoperate well with the codecs we field. So using some >>> time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't >>> finished either. There's one sentence that needs to be removed.) >>> >>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >>> prefer to re-discuss based on the knowledge that some significant players >>> have actually changed their minds. >>> >>> At the moment, I don't see signs that any of the poll respondents have >>> said "I have changed my mind". >>> >>> Harald >>> >>> >>> >>> >>>> >>>> >>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson >>>>> wrote: >>>>> >>>>> On 16 October 2014 14:17, Matthew Kaufman wrote: >>>>>> And that's because something substantive has changed, or simply >>>>>> because >>>>>> wasting the WG time on this again is more entertaining than actually >>>>>> finishing a specification that can be independently implemented by all >>>>>> browser vendors? (A specification that we are nowhere near having, as >>>>>> far as >>>>>> I can tell) >>>>>> >>>>> Personally, I've found the reprieve from this fight refreshing. And >>>>> it would appear that we've made some real progress as a result. I'd >>>>> suggest that if we don't have new information, we continue to spend >>>>> our time productively. If we can't find topics to occupy our meeting >>>>> agenda time, then maybe we can free an agenda slot. >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Alex. Gouaillard, PhD, PhD, MBA >> >> ------------------------------------------------------------------------------------ >> CTO - Temasys Communications, S'pore / Mountain View >> President - CoSMo Software, Cambridge, MA >> >> ------------------------------------------------------------------------------------ >> sg.linkedin.com/agouaillard >> >> - >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c28eccf61aaa0505c8767a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"And its one of the issues holding up wider adoption = of the technology"

[BA] Specifying an MTI encoder/d= ecoder is not sufficient for interoperability.=C2=A0 It is also necessary t= o specify the transport in enough detail to allow independent implementatio= ns that interoperate well enough to be usable in a wide variety of scenario= s, including wireless networks where loss is commonly experienced. =C2=A0

We made the mistake of having an MTI discussion pre= viously with not enough details on that subject, particularly with respect = to H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best= . =C2=A0

So if we are to have the discussion again= , it should occur in the context of detailed specifications and interoperab= ility reports.

=C2=A0

=C2= =A0

On= Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
I&#= 39;m in favor of taking another run at this.

The working= group has repeatedly said that an MTI codec is something we need to produc= e. And its one of the issues holding up wider adoption of the technology (n= ot the only one for sure).

And things have changed= since the last meeting, a year ago now (November in Vancouver). Cisco'= s open264 plugin shipped and now just recently is integrated into Firefox. = iOS8 shipped with APIs for H264. There are other things worth noting. Will = this change the minds of everyone? Surely not. Will it sway enough for us t= o achieve rough consensus? Maybe. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD &= lt;agouaillard@g= mail.com> wrote:
+1 to not having MTI codec discussion unless some progress has bee= n made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing harald's = =C2=A0feeling that there was no change on the members position.=C2=A0
=

On Fri,= Oct 17, 2014 at 9:22 PM, Harald Alvestrand <harald@alvestrand.no= > wrote:
On 10/17/2014 12= :02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 A= nd
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



<= /div>--
Alex. Gouaillard= , PhD, PhD, MBA
-------------------------------------------------------= -----------------------------
CTO - Temasys Communications, S'= ;pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------= ------------------

  • =

_______________________________________________
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


--001a11c28eccf61aaa0505c8767a-- From nobody Sun Oct 19 09:13:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636ED1A1BBE for ; Sun, 19 Oct 2014 09:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EI4uYhH8gTZ for ; Sun, 19 Oct 2014 09:13:24 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434D31A1BC3 for ; Sun, 19 Oct 2014 09:13:24 -0700 (PDT) Received: by mail-oi0-f52.google.com with SMTP id a3so2585951oib.39 for ; Sun, 19 Oct 2014 09:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7dzoTs6CkzSGimUZl2sn/UuXgGPazVxXGy42u2S9taY=; b=yA8iKUVKaHG9WMQTyXu9xRyChaS4yZ+0jdPiPAx+swaJDpd8C+CIvX0fTHarzJy94Y mDxYidJiCq85MpmU+hrIiXzK0/Ur+ScyrBFrZARlWRW0t/Xz6NHbv+muBNem841SJAeD jaLOgZsq+KdWeNiVBpV4Fm2i58TkZSQxABh4F9Aznay2CUmAiXTpv3SgVd20y1bJujTQ 7BnS95iOrOK+Guefp+T7/T/6Jz0iA+z/RcGS6/obXqujIZJ19rb+DIZEJMUcfBnnCNhC PrEvjghAlbosgD7AKBxvkPc8dD/lz7vAoUcsYp7qGKVA8HUDbD0oAGUYJCn0X4D53ty0 mdkQ== MIME-Version: 1.0 X-Received: by 10.202.102.162 with SMTP id m34mr17360211oik.37.1413735203621; Sun, 19 Oct 2014 09:13:23 -0700 (PDT) Received: by 10.202.66.5 with HTTP; Sun, 19 Oct 2014 09:13:23 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Date: Mon, 20 Oct 2014 00:13:23 +0800 Message-ID: From: Alexandre GOUAILLARD To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a1140a9be9e52360505c8e061 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/k6AFr7ZKgXFwqYXVKyKGDzvMFi4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 16:13:27 -0000 --001a1140a9be9e52360505c8e061 Content-Type: text/plain; charset=UTF-8 @jonathan, while you are right and availability of 264 implementation or hardware acceleration has improved, it has never been reported as a problem in the previous pool by anyone. The 264 royalties, and the VP8 IP risks were, AFAIR, the main reasons used by individuals to justify their positions. Today, nothing has changed with respect to those two items (even though providing open264 royalties and absorbing the license cost for some platforms might have been a set in the right direction). This is why I think the conditions are not met for a consensus to be reached. Alex. On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba wrote: > "And its one of the issues holding up wider adoption of the technology" > > [BA] Specifying an MTI encoder/decoder is not sufficient for > interoperability. It is also necessary to specify the transport in enough > detail to allow independent implementations that interoperate well enough > to be usable in a wide variety of scenarios, including wireless networks > where loss is commonly experienced. > > We made the mistake of having an MTI discussion previously with not enough > details on that subject, particularly with respect to H.264. > draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > > So if we are to have the discussion again, it should occur in the context > of detailed specifications and interoperability reports. > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: > >> I'm in favor of taking another run at this. >> >> The working group has repeatedly said that an MTI codec is something we >> need to produce. And its one of the issues holding up wider adoption of the >> technology (not the only one for sure). >> >> And things have changed since the last meeting, a year ago now (November >> in Vancouver). Cisco's open264 plugin shipped and now just recently is >> integrated into Firefox. iOS8 shipped with APIs for H264. There are other >> things worth noting. Will this change the minds of everyone? Surely not. >> Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth >> finding out. >> >> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < >> agouaillard@gmail.com> wrote: >> >>> +1 to not having MTI codec discussion unless some progress has been made >>> on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that there >>> was no change on the members position. >>> >>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand >> > wrote: >>> >>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>> >>>>> One thing we could do instead of wasting time on MTI is to actually >>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >>>>> actually interoperate regardless of the codec. >>>>> >>>> >>>> The big argument for an MTI is actually the one stated in -overview: It >>>> guards against interoperability failure. >>>> >>>> I would like to have an ecosystem where one can field a box, connect it >>>> to everything else, and run well for *some* level of "well" - and I would >>>> prefer that ecosystem to be one where it's possible to field the box >>>> without making prior arrangements with anyone about licenses. >>>> >>>> This argument hasn't changed one whit since last time we discussed it. >>>> And I don't see much movement on the specifics of the proposals either. >>>> >>>> We'll have to interoperate well with the codecs we field. So using some >>>> time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't >>>> finished either. There's one sentence that needs to be removed.) >>>> >>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >>>> prefer to re-discuss based on the knowledge that some significant players >>>> have actually changed their minds. >>>> >>>> At the moment, I don't see signs that any of the poll respondents have >>>> said "I have changed my mind". >>>> >>>> Harald >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson >>>>>> wrote: >>>>>> >>>>>> On 16 October 2014 14:17, Matthew Kaufman >>>>>>> wrote: >>>>>>> And that's because something substantive has changed, or simply >>>>>>> because >>>>>>> wasting the WG time on this again is more entertaining than actually >>>>>>> finishing a specification that can be independently implemented by >>>>>>> all >>>>>>> browser vendors? (A specification that we are nowhere near having, >>>>>>> as far as >>>>>>> I can tell) >>>>>>> >>>>>> Personally, I've found the reprieve from this fight refreshing. And >>>>>> it would appear that we've made some real progress as a result. I'd >>>>>> suggest that if we don't have new information, we continue to spend >>>>>> our time productively. If we can't find topics to occupy our meeting >>>>>> agenda time, then maybe we can free an agenda slot. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> Alex. Gouaillard, PhD, PhD, MBA >>> >>> ------------------------------------------------------------------------------------ >>> CTO - Temasys Communications, S'pore / Mountain View >>> President - CoSMo Software, Cambridge, MA >>> >>> ------------------------------------------------------------------------------------ >>> sg.linkedin.com/agouaillard >>> >>> - >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> >> >> -- >> Jonathan Rosenberg, Ph.D. >> jdrosen@jdrosen.net >> http://www.jdrosen.net >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - --001a1140a9be9e52360505c8e061 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
@jonathan,

while you are right and avai= lability of 264 implementation or hardware acceleration has improved, it ha= s never been reported as a problem in the previous pool by anyone. The 264 = royalties, and the VP8 IP risks were, AFAIR, the main reasons used by indiv= iduals to justify their positions. Today, nothing has changed with respect = to those two items (even though providing open264 royalties and absorbing t= he license cost for some platforms might have been a set in the right direc= tion). This is why I think the conditions are not met for a consensus to be= reached.

Alex.


On Sun, Oct 19, 2014 at 1= 1:43 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote= :
"= ;And its one of the issues holding up wider adoption of the technology"= ;

[BA] Specifying an MTI encoder/decoder is not s= ufficient for interoperability.=C2=A0 It is also necessary to specify the t= ransport in enough detail to allow independent implementations that interop= erate well enough to be usable in a wide variety of scenarios, including wi= reless networks where loss is commonly experienced. =C2=A0

We made the mistake of having an MTI discussion previously with no= t enough details on that subject, particularly with respect to H.264. draft= -ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. =C2=A0
<= div>
So if we are to have the discussion again, it should occ= ur in the context of detailed specifications and interoperability reports.<= /div>

=C2=A0

=C2=A0
=

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrosen.net> wrote:
I'm in favor of taking another run at this.
<= br>
The working group has repeatedly said that an MTI codec is so= mething we need to produce. And its one of the issues holding up wider adop= tion of the technology (not the only one for sure).

And things have changed since the last meeting, a year ago now (November = in Vancouver). Cisco's open264 plugin shipped and now just recently is = integrated into Firefox. iOS8 shipped with APIs for H264. There are other t= hings worth noting. Will this change the minds of everyone? Surely not. Wil= l it sway enough for us to achieve rough consensus? Maybe. IMHO - worth fin= ding out.

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <a= gouaillard@gmail.com> wrote:
+1 to not having MTI codec discussion unless some progre= ss has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing har= ald's =C2=A0feeling that there was no change on the members position.= =C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:
On 10/= 17/2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 A= nd
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



<= /div>--
Alex. Gouaillard= , PhD, PhD, MBA
-------------------------------------------------------= -----------------------------
CTO - Temasys Communications, S'= ;pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------= ------------------

  • =

_______________________________________________
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





--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------

--001a1140a9be9e52360505c8e061-- From nobody Sun Oct 19 09:15:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA03A1A1BD6 for ; Sun, 19 Oct 2014 09:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96O6hChlG4tn for ; Sun, 19 Oct 2014 09:15:18 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBBA1A1BCC for ; Sun, 19 Oct 2014 09:15:18 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id z6so1909839yhz.13 for ; Sun, 19 Oct 2014 09:15:17 -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=B4IQFT9dYjoCHNmSHkvJA3mfSj+wIctGsFdVuV58v6Y=; b=Y9U1g4n2stjsqG5aSAEB4P3ZmhXOBYA3MXkmhArApAbd7EvAw7A3tjfQ8FgD5su5hs /Z6msxKN/Dv1D6ysvfWbuza+prthsJ/cGqVMixPV7RcI5rdZI3eD6edZdbi40bh4r3vH SGfT5elIzB7W1RfUXw2M2uOMI7O1WV4y7goDWvw3yaPkHvztDqwd4Nj/FyAi1w89HsBJ GARV05N6cE2t/zOWtgciRPEduiNaK8vztdV88LwMrTkxTfQKzxwhsxwl5YD0f0dl4ILT ByW8c7Iyi/1UK6FSiUIJ5GuXK7P9YYK+NAi4Umkg+TIy9rL61hBXESBc6byFFg9Ccnc7 3T7A== MIME-Version: 1.0 X-Received: by 10.236.30.197 with SMTP id k45mr3720896yha.163.1413735317277; Sun, 19 Oct 2014 09:15:17 -0700 (PDT) Received: by 10.170.195.149 with HTTP; Sun, 19 Oct 2014 09:15:17 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Date: Sun, 19 Oct 2014 09:15:17 -0700 Message-ID: From: Watson Ladd To: Alexandre GOUAILLARD Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NDVp3s4PH4AKEEFbxzNiuSgolos Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 16:15:21 -0000 On Sun, Oct 19, 2014 at 9:13 AM, Alexandre GOUAILLARD wrote: > @jonathan, > > while you are right and availability of 264 implementation or hardware > acceleration has improved, it has never been reported as a problem in the > previous pool by anyone. The 264 royalties, and the VP8 IP risks were, > AFAIR, the main reasons used by individuals to justify their positions. > Today, nothing has changed with respect to those two items (even though > providing open264 royalties and absorbing the license cost for some > platforms might have been a set in the right direction). This is why I think > the conditions are not met for a consensus to be reached. But now VP8 is going through ISO, and the people claiming patents on VP8 have had time to sue, and haven't. That's evidence that some concerns are overblown. > > Alex. > > > On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba > wrote: >> >> "And its one of the issues holding up wider adoption of the technology" >> >> [BA] Specifying an MTI encoder/decoder is not sufficient for >> interoperability. It is also necessary to specify the transport in enough >> detail to allow independent implementations that interoperate well enough to >> be usable in a wide variety of scenarios, including wireless networks where >> loss is commonly experienced. >> >> We made the mistake of having an MTI discussion previously with not enough >> details on that subject, particularly with respect to H.264. >> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. >> >> So if we are to have the discussion again, it should occur in the context >> of detailed specifications and interoperability reports. >> >> >> >> >> >> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg >> wrote: >>> >>> I'm in favor of taking another run at this. >>> >>> The working group has repeatedly said that an MTI codec is something we >>> need to produce. And its one of the issues holding up wider adoption of the >>> technology (not the only one for sure). >>> >>> And things have changed since the last meeting, a year ago now (November >>> in Vancouver). Cisco's open264 plugin shipped and now just recently is >>> integrated into Firefox. iOS8 shipped with APIs for H264. There are other >>> things worth noting. Will this change the minds of everyone? Surely not. >>> Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth >>> finding out. >>> >>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD >>> wrote: >>>> >>>> +1 to not having MTI codec discussion unless some progress has been made >>>> on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that there >>>> was no change on the members position. >>>> >>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand >>>> wrote: >>>>> >>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>>>> >>>>>> One thing we could do instead of wasting time on MTI is to actually >>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >>>>>> actually interoperate regardless of the codec. >>>>> >>>>> >>>>> The big argument for an MTI is actually the one stated in -overview: It >>>>> guards against interoperability failure. >>>>> >>>>> I would like to have an ecosystem where one can field a box, connect it >>>>> to everything else, and run well for *some* level of "well" - and I would >>>>> prefer that ecosystem to be one where it's possible to field the box without >>>>> making prior arrangements with anyone about licenses. >>>>> >>>>> This argument hasn't changed one whit since last time we discussed it. >>>>> And I don't see much movement on the specifics of the proposals either. >>>>> >>>>> We'll have to interoperate well with the codecs we field. So using some >>>>> time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't >>>>> finished either. There's one sentence that needs to be removed.) >>>>> >>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >>>>> prefer to re-discuss based on the knowledge that some significant players >>>>> have actually changed their minds. >>>>> >>>>> At the moment, I don't see signs that any of the poll respondents have >>>>> said "I have changed my mind". >>>>> >>>>> Harald >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson >>>>>>> wrote: >>>>>>> >>>>>>>> On 16 October 2014 14:17, Matthew Kaufman >>>>>>>> wrote: >>>>>>>> And that's because something substantive has changed, or simply >>>>>>>> because >>>>>>>> wasting the WG time on this again is more entertaining than actually >>>>>>>> finishing a specification that can be independently implemented by >>>>>>>> all >>>>>>>> browser vendors? (A specification that we are nowhere near having, >>>>>>>> as far as >>>>>>>> I can tell) >>>>>>> >>>>>>> Personally, I've found the reprieve from this fight refreshing. And >>>>>>> it would appear that we've made some real progress as a result. I'd >>>>>>> suggest that if we don't have new information, we continue to spend >>>>>>> our time productively. If we can't find topics to occupy our meeting >>>>>>> agenda time, then maybe we can free an agenda slot. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>>> >>>> >>>> -- >>>> Alex. Gouaillard, PhD, PhD, MBA >>>> >>>> ------------------------------------------------------------------------------------ >>>> CTO - Temasys Communications, S'pore / Mountain View >>>> President - CoSMo Software, Cambridge, MA >>>> >>>> ------------------------------------------------------------------------------------ >>>> sg.linkedin.com/agouaillard >>>> >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >>> >>> >>> -- >>> Jonathan Rosenberg, Ph.D. >>> jdrosen@jdrosen.net >>> http://www.jdrosen.net >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> > > > > -- > Alex. Gouaillard, PhD, PhD, MBA > ------------------------------------------------------------------------------------ > CTO - Temasys Communications, S'pore / Mountain View > President - CoSMo Software, Cambridge, MA > ------------------------------------------------------------------------------------ > sg.linkedin.com/agouaillard > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Oct 19 11:00:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E791A1A71 for ; Sun, 19 Oct 2014 11:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhGzcHzfID_T for ; Sun, 19 Oct 2014 11:00:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9171A19FE for ; Sun, 19 Oct 2014 11:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14013; q=dns/txt; s=iport; t=1413741601; x=1414951201; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=W5RZnFd7nzhvaO5ZDkaVT1e4OgxlawJQI2pbYldDOAw=; b=EJVl2vr/E3u8LkLILIjm8zZ7RDN3SB4ZCoyCk3s7r2IXI+5pO27dGpmB elvaLqEY2n2j4gFmuzExxKxWJ705yK6dnF/is7YAcqzRTBhkRznHxF5oB 0zbr9IDQ3kbsgzSZKk7DmPbbi8aaS04A0zQCYgFx9HkdXQ6dh0JpJdOkP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAFH6Q1StJV2P/2dsb2JhbABbgkVGU1jKJ4FmAQmGelQCgQ4WAXILhAMBAQQBAQFSGRsCAQg/ByEGCxQRAgQTGogRAxENuRMNhjEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjh2CMAuDLYEeBYYti1OERoUCghGPSIZagV2CGmyCSwEBAQ X-IronPort-AV: E=Sophos;i="5.04,749,1406592000"; d="scan'208,217";a="364582417" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 19 Oct 2014 18:00:00 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9JHxxqr020140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 19 Oct 2014 17:59:59 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.63]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 12:59:59 -0500 From: "Jeremy Laurenson (jlaurens)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP669o0YA0VVXvZkG/wkm6G20Ux5w3tZ/C Date: Sun, 19 Oct 2014 17:59:58 +0000 Message-ID: <16C290A2-EB7C-4D77-8871-C7E82B374C48@cisco.com> References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_16C290A2EB7C4D778871C7E82B374C48ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ejCFdFcVuxWAOgVI5iBOepw62YE Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 18:00:03 -0000 --_000_16C290A2EB7C4D778871C7E82B374C48ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am hearing a lot of folks outside this group losing faith and beginning t= o talk about writing off WebRTC for lack of consensus (including analysts). I am therefore in favor of a very finite amount of "new-news" discussion an= d another attempt at consensus. We either do or don't have it. On Oct 19, 2014, at 11:15 AM, Jonathan Rosenberg > wrote: I'm in favor of taking another run at this. The working group has repeatedly said that an MTI codec is something we nee= d to produce. And its one of the issues holding up wider adoption of the te= chnology (not the only one for sure). And things have changed since the last meeting, a year ago now (November in= Vancouver). Cisco's open264 plugin shipped and now just recently is integr= ated into Firefox. iOS8 shipped with APIs for H264. There are other things = worth noting. Will this change the minds of everyone? Surely not. Will it s= way enough for us to achieve rough consensus? Maybe. IMHO - worth finding o= ut. On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD > wrote: +1 to not having MTI codec discussion unless some progress has been made on= VP8 at MPEG. Any news on that? I'm sharing harald's feeling that there wa= s no change on the members position. On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: On 10/17/2014 12:02 AM, Bernard Aboba wrote: One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec. The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure. I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I would pref= er that ecosystem to be one where it's possible to field the box without ma= king prior arrangements with anyone about licenses. This argument hasn't changed one whit since last time we discussed it. And = I don't see much movement on the specifics of the proposals either. We'll have to interoperate well with the codecs we field. So using some tim= e to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't fi= nished either. There's one sentence that needs to be removed.) I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer= to re-discuss based on the knowledge that some significant players have ac= tually changed their minds. At the moment, I don't see signs that any of the poll respondents have said= "I have changed my mind". Harald On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: On 16 October 2014 14:17, Matthew Kaufman > wrote: And that's because something substantive has changed, or simply because wasting the WG time on this again is more entertaining than actually finishing a specification that can be independently implemented by all browser vendors? (A specification that we are nowhere near having, as far a= s I can tell) Personally, I've found the reprieve from this fight refreshing. And it would appear that we've made some real progress as a result. I'd suggest that if we don't have new information, we continue to spend our time productively. If we can't find topics to occupy our meeting agenda time, then maybe we can free an agenda slot. _______________________________________________ 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 -- Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard * _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_16C290A2EB7C4D778871C7E82B374C48ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am hearing a lot of folks outside this group losing faith and beginn= ing to talk about writing off WebRTC for lack of consensus (including analy= sts).

I am therefore in favor of a very finite amount of "new-news"= ; discussion and another attempt at consensus. We either do or don't have i= t.


On Oct 19, 2014, at 11:15 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:

I'm in favor of taking another run at this.

The working group has repeatedly said that an MTI codec is something w= e need to produce. And its one of the issues holding up wider adoption of t= he technology (not the only one for sure).

And things have changed since the last meeting, a year ago now (Novemb= er in Vancouver). Cisco's open264 plugin shipped and now just recently is i= ntegrated into Firefox. iOS8 shipped with APIs for H264. There are other th= ings worth noting. Will this change the minds of everyone? Surely not. Will it sway enough for us to achieve r= ough consensus? Maybe. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAI= LLARD <agouaillard@= gmail.com> wrote:
+1 to not having MTI codec discussion unless some prog= ress has been made on VP8 at MPEG. Any news on that? I'm sharing haral= d's  feeling that there was no change on the members position. 

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestra= nd <harald@alvest= rand.no> wrote:
On 10/17/2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

The big argument for an MTI is actually the one stated in -overview:= It guards against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the box = without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. And = I don't see much movement on the specifics of the proposals either.

We'll have to interoperate well with the codecs we field. So using some tim= e to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't fi= nished either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer= to re-discuss based on the knowledge that some significant players have ac= tually changed their minds.

At the moment, I don't see signs that any of the poll respondents have said= "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.  And it would appear that we've made some real progress as a result.  I'd suggest that if we don't have new information, we continue to spend
our time productively.  If we can't find topics to occupy our meeting<= br> agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



--
Alex. Gouaillard, PhD, PhD, MBA
----------------------------------------------------------------------= --------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
----------------------------------------------------------------------= --------------


_______________________________________________
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_16C290A2EB7C4D778871C7E82B374C48ciscocom_-- From nobody Sun Oct 19 11:13:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7E11A1AAE for ; Sun, 19 Oct 2014 11:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY_gunhF80GM for ; Sun, 19 Oct 2014 11:13:34 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF88E1A1A15 for ; Sun, 19 Oct 2014 11:13:33 -0700 (PDT) Received: from mail-wi0-f175.google.com ([209.85.212.175]:53052) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xfuyp-0005Yp-U1 for rtcweb@ietf.org; Sun, 19 Oct 2014 14:13:32 -0400 Received: by mail-wi0-f175.google.com with SMTP id d1so5463653wiv.8 for ; Sun, 19 Oct 2014 11:13:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.2.129 with SMTP id 1mr27643008wju.12.1413742403386; Sun, 19 Oct 2014 11:13:23 -0700 (PDT) Received: by 10.194.120.66 with HTTP; Sun, 19 Oct 2014 11:13:23 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Date: Sun, 19 Oct 2014 14:13:23 -0400 Message-ID: From: Jonathan Rosenberg To: Alexandre GOUAILLARD Content-Type: multipart/alternative; boundary=047d7b343d30c2041f0505ca8d8e X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1S5b0jD9oKoL-fIfuBAno194CqA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 18:13:36 -0000 --047d7b343d30c2041f0505ca8d8e Content-Type: text/plain; charset=UTF-8 @Alexandre - you say "Today, nothing has changed with respect to those two items (even though providing open264 royalties and absorbing the license cost for some platforms might have been a set in the right direction). ". But, as you say, the availability of Firefox with H264 is a change (previously it was not yet available); the fact that Cisco has in fact fronted the cost is a change (at the last meeting some were skeptical this would happen, but it has). The other big news was IOS8, which now enables apps to access H264 and Apple pays the cost. Last time, the lack of a solution on IOS was a big deal. That is also now, no longer an issue. As such I think there are material changes. On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD < agouaillard@gmail.com> wrote: > @jonathan, > > while you are right and availability of 264 implementation or hardware > acceleration has improved, it has never been reported as a problem in the > previous pool by anyone. The 264 royalties, and the VP8 IP risks were, > AFAIR, the main reasons used by individuals to justify their positions. > Today, nothing has changed with respect to those two items (even though > providing open264 royalties and absorbing the license cost for some > platforms might have been a set in the right direction). This is why I > think the conditions are not met for a consensus to be reached. > > Alex. > > > On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba > wrote: > >> "And its one of the issues holding up wider adoption of the technology" >> >> [BA] Specifying an MTI encoder/decoder is not sufficient for >> interoperability. It is also necessary to specify the transport in enough >> detail to allow independent implementations that interoperate well enough >> to be usable in a wide variety of scenarios, including wireless networks >> where loss is commonly experienced. >> >> We made the mistake of having an MTI discussion previously with not >> enough details on that subject, particularly with respect to H.264. >> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. >> >> So if we are to have the discussion again, it should occur in the context >> of detailed specifications and interoperability reports. >> >> >> >> >> >> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg >> wrote: >> >>> I'm in favor of taking another run at this. >>> >>> The working group has repeatedly said that an MTI codec is something we >>> need to produce. And its one of the issues holding up wider adoption of the >>> technology (not the only one for sure). >>> >>> And things have changed since the last meeting, a year ago now (November >>> in Vancouver). Cisco's open264 plugin shipped and now just recently is >>> integrated into Firefox. iOS8 shipped with APIs for H264. There are other >>> things worth noting. Will this change the minds of everyone? Surely not. >>> Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth >>> finding out. >>> >>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < >>> agouaillard@gmail.com> wrote: >>> >>>> +1 to not having MTI codec discussion unless some progress has been >>>> made on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that >>>> there was no change on the members position. >>>> >>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand < >>>> harald@alvestrand.no> wrote: >>>> >>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>>> >>>>>> One thing we could do instead of wasting time on MTI is to actually >>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >>>>>> actually interoperate regardless of the codec. >>>>>> >>>>> >>>>> The big argument for an MTI is actually the one stated in -overview: >>>>> It guards against interoperability failure. >>>>> >>>>> I would like to have an ecosystem where one can field a box, connect >>>>> it to everything else, and run well for *some* level of "well" - and I >>>>> would prefer that ecosystem to be one where it's possible to field the box >>>>> without making prior arrangements with anyone about licenses. >>>>> >>>>> This argument hasn't changed one whit since last time we discussed it. >>>>> And I don't see much movement on the specifics of the proposals either. >>>>> >>>>> We'll have to interoperate well with the codecs we field. So using >>>>> some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 >>>>> isn't finished either. There's one sentence that needs to be removed.) >>>>> >>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >>>>> prefer to re-discuss based on the knowledge that some significant players >>>>> have actually changed their minds. >>>>> >>>>> At the moment, I don't see signs that any of the poll respondents have >>>>> said "I have changed my mind". >>>>> >>>>> Harald >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson < >>>>>>> martin.thomson@gmail.com> wrote: >>>>>>> >>>>>>> On 16 October 2014 14:17, Matthew Kaufman >>>>>>>> wrote: >>>>>>>> And that's because something substantive has changed, or simply >>>>>>>> because >>>>>>>> wasting the WG time on this again is more entertaining than actually >>>>>>>> finishing a specification that can be independently implemented by >>>>>>>> all >>>>>>>> browser vendors? (A specification that we are nowhere near having, >>>>>>>> as far as >>>>>>>> I can tell) >>>>>>>> >>>>>>> Personally, I've found the reprieve from this fight refreshing. And >>>>>>> it would appear that we've made some real progress as a result. I'd >>>>>>> suggest that if we don't have new information, we continue to spend >>>>>>> our time productively. If we can't find topics to occupy our meeting >>>>>>> agenda time, then maybe we can free an agenda slot. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Alex. Gouaillard, PhD, PhD, MBA >>>> >>>> ------------------------------------------------------------------------------------ >>>> CTO - Temasys Communications, S'pore / Mountain View >>>> President - CoSMo Software, Cambridge, MA >>>> >>>> ------------------------------------------------------------------------------------ >>>> sg.linkedin.com/agouaillard >>>> >>>> - >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>> >>> >>> -- >>> Jonathan Rosenberg, Ph.D. >>> jdrosen@jdrosen.net >>> http://www.jdrosen.net >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> > > > -- > Alex. Gouaillard, PhD, PhD, MBA > > ------------------------------------------------------------------------------------ > CTO - Temasys Communications, S'pore / Mountain View > President - CoSMo Software, Cambridge, MA > > ------------------------------------------------------------------------------------ > sg.linkedin.com/agouaillard > > - > > -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --047d7b343d30c2041f0505ca8d8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
@Alexandre - you say "Today, nothing has changed with respect to tho= se two items (even though providing open264 royalties and absorbing the lic= ense cost for some platforms might have been a set in the right direction).= =C2=A0". But, as you say, the availability of Firefox with H264 is a c= hange (previously it was not yet available); the fact that Cisco has in fac= t fronted the cost is a change (at the last meeting some were skeptical thi= s would happen, but it has). The other big news was IOS8, which now enables= apps to access H264 and Apple pays the cost. Last time, the lack of a solu= tion on IOS was a big deal. That is also now, no longer an issue. As such I= think there are material changes.


On Sun, Oct 19, 2014 at 12:13 PM, Alex= andre GOUAILLARD <agouaillard@gmail.com> wrote:
@jonathan,

wh= ile you are right and availability of 264 implementation or hardware accele= ration has improved, it has never been reported as a problem in the previou= s pool by anyone. The 264 royalties, and the VP8 IP risks were, AFAIR, the = main reasons used by individuals to justify their positions. Today, nothing= has changed with respect to those two items (even though providing open264= royalties and absorbing the license cost for some platforms might have bee= n a set in the right direction). This is why I think the conditions are not= met for a consensus to be reached.

Alex.


On Sun, Oct 19, 2014 at 11:43 PM, = Bernard Aboba <bernard.aboba@gmail.com> wrote:
"And its one of the = issues holding up wider adoption of the technology"

[BA] Specifying an MTI encoder/decoder is not sufficient for intero= perability.=C2=A0 It is also necessary to specify the transport in enough d= etail to allow independent implementations that interoperate well enough to= be usable in a wide variety of scenarios, including wireless networks wher= e loss is commonly experienced. =C2=A0

We made the= mistake of having an MTI discussion previously with not enough details on = that subject, particularly with respect to H.264. draft-ietf-rtcweb-video s= ections 4.2 - 4.4 remain sketchy at best. =C2=A0

S= o if we are to have the discussion again, it should occur in the context of= detailed specifications and interoperability reports.

=
=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:1= 4 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
I'm in favor of taking a= nother run at this.

The working group has repeatedly sai= d that an MTI codec is something we need to produce. And its one of the iss= ues holding up wider adoption of the technology (not the only one for sure)= .

And things have changed since the last meeting, = a year ago now (November in Vancouver). Cisco's open264 plugin shipped = and now just recently is integrated into Firefox. iOS8 shipped with APIs fo= r H264. There are other things worth noting. Will this change the minds of = everyone? Surely not. Will it sway enough for us to achieve rough consensus= ? Maybe. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:08 PM, Ale= xandre GOUAILLARD <agouaillard@gmail.com> wrote:
+1 to not having MTI codec disc= ussion unless some progress has been made on VP8 at MPEG.=C2=A0Any news on = that? I'm sharing harald's =C2=A0feeling that there was no change o= n the members position.=C2=A0
On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestr= and <harald@alvestrand.no> wrote:
On 10/17/2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 A= nd
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



<= /div>--
Alex. Gouaillard= , PhD, PhD, MBA
-------------------------------------------------------= -----------------------------
CTO - Temasys Communications, S'= ;pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------= ------------------

  • =

_______________________________________________
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





--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------




--
=
--047d7b343d30c2041f0505ca8d8e-- From nobody Sun Oct 19 11:46:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60141A1ADF for ; Sun, 19 Oct 2014 11:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0pe-jRrPV4x for ; Sun, 19 Oct 2014 11:46:42 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA201A1AC9 for ; Sun, 19 Oct 2014 11:46:42 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id uz6so2815395obc.15 for ; Sun, 19 Oct 2014 11:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QF1+200+oUHLFoZNMTiM4aFf+hrKNH7aCottrSHMBf4=; b=efeyVM6QRHpLR157RC556F8KPHMfk164Km7ZkwctcsZHQKoi3shSzgpiySethPzb40 YSINVUqyvPDGBvXvaxtt2SvV5ZO+dp2PJ1kPxwjqCtIIdOboYql0CVzTuA7HJQJxodQ7 31CShQftllWrgXOdeET1uKeHzPfFqhdT/lZKj5I7ZoRJQUdELEHTY2B0TUURXPpEll9N CGD1QsPpVVEFQZqhv+cfVG2Fw65309Vel/ZYft3ZSkOLAJCN9RliMypArWca67XyuMYY 2TyPoiKHI507bHgY/Th9eyqAnjXpDE/V3inxe4aHWhMOTSX4kjPc+Td2HudFwaB500ih agWw== MIME-Version: 1.0 X-Received: by 10.182.102.98 with SMTP id fn2mr19188031obb.15.1413744401598; Sun, 19 Oct 2014 11:46:41 -0700 (PDT) Received: by 10.202.66.5 with HTTP; Sun, 19 Oct 2014 11:46:41 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Date: Mon, 20 Oct 2014 02:46:41 +0800 Message-ID: From: Alexandre GOUAILLARD To: Jonathan Rosenberg Content-Type: multipart/alternative; boundary=089e013c5d2cdc53cb0505cb049b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r_w5gEKHCGEngiouuM3YwrV_PGM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 18:46:46 -0000 --089e013c5d2cdc53cb0505cb049b Content-Type: text/plain; charset=UTF-8 @watson I would prefer the ISO process to see through before deciding. That's why I keep bothering harald for news at every meeting ;-) If for any reason it does not happen, we're back where we were when we did the last pool. Nobody has sued .... yet, does not mean there is no IP risk. Actually, there were at least 3 counts of nokia suing, but the three cases were negotiated and the result is not available to the public. (here ) @jonathan Point taken, I hadn't thought about the implications of H264 hardware acceleration. If indeed it leverages the need to get a license, that makes the situation better. Would that be enough ...? We could map all the cases and see what is left to be dealt with. In any case, deciding about 264 without looking at 265 seems shortsighted, and I am not aware of any binary, or hardware acceleration support available for 265 yet (even though iPhone 6 claims to supports 265 acc in its specs, I'm not aware of API that would allow native app to leverage this capacity). Correct me if I'm wrong or if I'm missing anything (anyone): -- desktop browsers -- - firefox, let's assume the 264 binary is used. It also supports VP8. - chrome on desktop supports vp8 but not 264 (as far as webrtc is concerned, the media element supports 264 playback). - what about IE / Safari ? I don't think apple will make a statement, but I remember reading that microsoft would support 264 (at least for media element playback) if it is available on the system. Bernard / shijun, any comment about which codec would be used for ORTC/webRTC? -- mobile browsers -- - no firefox on iOS. What about the android version, what does it support? - chrome supports only VP8, and can't support webRTC on iOS anyway (even though justin is working on a audio-only, API-injection-in-webkit solution). - opera? -- mobile native -- - iOS 8+ has system API for hw acc 264 - android has system API for both hw acc 264 and VP8 (is it true?) - the webrtc.org stack does not support 264 even though kaiduan die from blackberry provided a patch for this - the ericson's openwebrtc stack supports 264 in multiple ways (does it support hw acc?) but lack support for Windows and data channel. -- Others -- - lots of MCUs / SFUs / Gateways would need 264 in more cases than just the interoperability between webrtc and SIP, and I'm not sure the cisco binaries can be used there. On Mon, Oct 20, 2014 at 2:13 AM, Jonathan Rosenberg wrote: > @Alexandre - you say "Today, nothing has changed with respect to those > two items (even though providing open264 royalties and absorbing the > license cost for some platforms might have been a set in the right > direction). ". But, as you say, the availability of Firefox with H264 is a > change (previously it was not yet available); the fact that Cisco has in > fact fronted the cost is a change (at the last meeting some were skeptical > this would happen, but it has). The other big news was IOS8, which now > enables apps to access H264 and Apple pays the cost. Last time, the lack of > a solution on IOS was a big deal. That is also now, no longer an issue. As > such I think there are material changes. > > > On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD < > agouaillard@gmail.com> wrote: > >> @jonathan, >> >> while you are right and availability of 264 implementation or hardware >> acceleration has improved, it has never been reported as a problem in the >> previous pool by anyone. The 264 royalties, and the VP8 IP risks were, >> AFAIR, the main reasons used by individuals to justify their positions. >> Today, nothing has changed with respect to those two items (even though >> providing open264 royalties and absorbing the license cost for some >> platforms might have been a set in the right direction). This is why I >> think the conditions are not met for a consensus to be reached. >> >> Alex. >> >> >> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba >> wrote: >> >>> "And its one of the issues holding up wider adoption of the technology" >>> >>> [BA] Specifying an MTI encoder/decoder is not sufficient for >>> interoperability. It is also necessary to specify the transport in enough >>> detail to allow independent implementations that interoperate well enough >>> to be usable in a wide variety of scenarios, including wireless networks >>> where loss is commonly experienced. >>> >>> We made the mistake of having an MTI discussion previously with not >>> enough details on that subject, particularly with respect to H.264. >>> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. >>> >>> So if we are to have the discussion again, it should occur in the >>> context of detailed specifications and interoperability reports. >>> >>> >>> >>> >>> >>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg >> > wrote: >>> >>>> I'm in favor of taking another run at this. >>>> >>>> The working group has repeatedly said that an MTI codec is something we >>>> need to produce. And its one of the issues holding up wider adoption of the >>>> technology (not the only one for sure). >>>> >>>> And things have changed since the last meeting, a year ago now >>>> (November in Vancouver). Cisco's open264 plugin shipped and now just >>>> recently is integrated into Firefox. iOS8 shipped with APIs for H264. There >>>> are other things worth noting. Will this change the minds of everyone? >>>> Surely not. Will it sway enough for us to achieve rough consensus? Maybe. >>>> IMHO - worth finding out. >>>> >>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < >>>> agouaillard@gmail.com> wrote: >>>> >>>>> +1 to not having MTI codec discussion unless some progress has been >>>>> made on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that >>>>> there was no change on the members position. >>>>> >>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand < >>>>> harald@alvestrand.no> wrote: >>>>> >>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>>>> >>>>>>> One thing we could do instead of wasting time on MTI is to actually >>>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >>>>>>> actually interoperate regardless of the codec. >>>>>>> >>>>>> >>>>>> The big argument for an MTI is actually the one stated in -overview: >>>>>> It guards against interoperability failure. >>>>>> >>>>>> I would like to have an ecosystem where one can field a box, connect >>>>>> it to everything else, and run well for *some* level of "well" - and I >>>>>> would prefer that ecosystem to be one where it's possible to field the box >>>>>> without making prior arrangements with anyone about licenses. >>>>>> >>>>>> This argument hasn't changed one whit since last time we discussed >>>>>> it. And I don't see much movement on the specifics of the proposals either. >>>>>> >>>>>> We'll have to interoperate well with the codecs we field. So using >>>>>> some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 >>>>>> isn't finished either. There's one sentence that needs to be removed.) >>>>>> >>>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >>>>>> prefer to re-discuss based on the knowledge that some significant players >>>>>> have actually changed their minds. >>>>>> >>>>>> At the moment, I don't see signs that any of the poll respondents >>>>>> have said "I have changed my mind". >>>>>> >>>>>> Harald >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson < >>>>>>>> martin.thomson@gmail.com> wrote: >>>>>>>> >>>>>>>> On 16 October 2014 14:17, Matthew Kaufman >>>>>>>>> wrote: >>>>>>>>> And that's because something substantive has changed, or simply >>>>>>>>> because >>>>>>>>> wasting the WG time on this again is more entertaining than >>>>>>>>> actually >>>>>>>>> finishing a specification that can be independently implemented by >>>>>>>>> all >>>>>>>>> browser vendors? (A specification that we are nowhere near having, >>>>>>>>> as far as >>>>>>>>> I can tell) >>>>>>>>> >>>>>>>> Personally, I've found the reprieve from this fight refreshing. And >>>>>>>> it would appear that we've made some real progress as a result. I'd >>>>>>>> suggest that if we don't have new information, we continue to spend >>>>>>>> our time productively. If we can't find topics to occupy our >>>>>>>> meeting >>>>>>>> agenda time, then maybe we can free an agenda slot. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Alex. Gouaillard, PhD, PhD, MBA >>>>> >>>>> ------------------------------------------------------------------------------------ >>>>> CTO - Temasys Communications, S'pore / Mountain View >>>>> President - CoSMo Software, Cambridge, MA >>>>> >>>>> ------------------------------------------------------------------------------------ >>>>> sg.linkedin.com/agouaillard >>>>> >>>>> - >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>>> >>>> >>>> >>>> -- >>>> Jonathan Rosenberg, Ph.D. >>>> jdrosen@jdrosen.net >>>> http://www.jdrosen.net >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>> >> >> >> -- >> Alex. Gouaillard, PhD, PhD, MBA >> >> ------------------------------------------------------------------------------------ >> CTO - Temasys Communications, S'pore / Mountain View >> President - CoSMo Software, Cambridge, MA >> >> ------------------------------------------------------------------------------------ >> sg.linkedin.com/agouaillard >> >> - >> >> > > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - --089e013c5d2cdc53cb0505cb049b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
@watson

I would prefer the ISO process = to see through before deciding. That's why I keep bothering harald for = news at every meeting ;-) If for any reason it does not happen, we're b= ack where we were when we did the last pool.
Nobody has sued ....= yet, does not mean there is no IP risk. Actually, there were at least 3 co= unts of nokia suing, but the three cases were negotiated and the result is = not available to the public. (here)

=
@jonathan

Point taken, I hadn't thought a= bout the implications of H264 hardware acceleration. If indeed it leverages= the need to get a license, that makes the situation better. Would that be = enough ...? We could map all the cases and see what is left to be dealt wit= h. In any case, deciding about 264 without looking at 265 seems shortsighte= d, and I am not aware of any binary, or hardware acceleration support avail= able for 265 yet (even though iPhone 6 claims to supports 265 acc in its sp= ecs, I'm not aware of API that would allow native app to leverage this = capacity).=C2=A0

Correct me if I'm wrong or if= I'm missing anything (anyone):

-- desktop= browsers --
- firefox, let's assume the 264 binary is used. = It also supports VP8.
- chrome on desktop supports vp8 but not 26= 4 (as far as webrtc is concerned, the media element supports 264 playback).=
- what about IE / Safari ? I don't think apple will make a s= tatement, but I remember reading that microsoft would support 264 (at least= for media element playback) if it is available on the system. Bernard / sh= ijun, any comment about which codec would be used for ORTC/webRTC?

-- mobile browsers --
- no firefox on iOS. What = about the android version, what does it support?
- chrome support= s only VP8, and can't support webRTC on iOS anyway (even though justin = is working on a audio-only, API-injection-in-webkit solution).
- = opera?

-- mobile native --
- iOS 8+ has = system API for hw acc 264
- android has system API for both hw ac= c 264 and VP8 (is it true?)
- the w= ebrtc.org stack does not support 264 even though kaiduan die from black= berry provided a patch for this
- the ericson's openwebrtc st= ack supports 264 in multiple ways (does it support hw acc?) but lack suppor= t for Windows and data channel.

-- Others --
=
- lots of MCUs / SFUs / Gateways would need 264 in more cases than jus= t the interoperability between webrtc and SIP, and I'm not sure the cis= co binaries can be used there.=C2=A0
=
On Mon, Oct 20, 2014 at 2:13 AM, Jonathan Ro= senberg <jdrosen@jdrosen.net> wrote:
@Alexandre - you say "Today, nothing has changed with = respect to those two items (even though providing open264 royalties and abs= orbing the license cost for some platforms might have been a set in the rig= ht direction).=C2=A0". But, as you say, the availability of Firefox wi= th H264 is a change (previously it was not yet available); the fact that Ci= sco has in fact fronted the cost is a change (at the last meeting some were= skeptical this would happen, but it has). The other big news was IOS8, whi= ch now enables apps to access H264 and Apple pays the cost. Last time, the = lack of a solution on IOS was a big deal. That is also now, no longer an is= sue. As such I think there are material changes.


On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:
@jonathan,

while you are right an= d availability of 264 implementation or hardware acceleration has improved,= it has never been reported as a problem in the previous pool by anyone. Th= e 264 royalties, and the VP8 IP risks were, AFAIR, the main reasons used by= individuals to justify their positions. Today, nothing has changed with re= spect to those two items (even though providing open264 royalties and absor= bing the license cost for some platforms might have been a set in the right= direction). This is why I think the conditions are not met for a consensus= to be reached.

Alex.


On Sun, O= ct 19, 2014 at 11:43 PM, Bernard Aboba <bernard.aboba@gmail.com&= gt; wrote:
= "And its one of the issues holding up wider adoption of the technology= "

[BA] Specifying an MTI encoder/decoder is = not sufficient for interoperability.=C2=A0 It is also necessary to specify = the transport in enough detail to allow independent implementations that in= teroperate well enough to be usable in a wide variety of scenarios, includi= ng wireless networks where loss is commonly experienced. =C2=A0
<= br>
We made the mistake of having an MTI discussion previously wi= th not enough details on that subject, particularly with respect to H.264. = draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. =C2=A0

So if we are to have the discussion again, it shoul= d occur in the context of detailed specifications and interoperability repo= rts.

=C2=A0

=C2=A0
<= /div>

On= Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
I&#= 39;m in favor of taking another run at this.

The working= group has repeatedly said that an MTI codec is something we need to produc= e. And its one of the issues holding up wider adoption of the technology (n= ot the only one for sure).

And things have changed= since the last meeting, a year ago now (November in Vancouver). Cisco'= s open264 plugin shipped and now just recently is integrated into Firefox. = iOS8 shipped with APIs for H264. There are other things worth noting. Will = this change the minds of everyone? Surely not. Will it sway enough for us t= o achieve rough consensus? Maybe. IMHO - worth finding out.

On Sat, Oct= 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <agouaillard@gmail.com&= gt; wrote:
+1 to = not having MTI codec discussion unless some progress has been made on VP8 a= t MPEG.=C2=A0Any news on that? I'm sharing harald's =C2=A0feeling t= hat there was no change on the members position.=C2=A0

On Fri, Oct 17, 2014 a= t 9:22 PM, Harald Alvestrand <harald@alvestrand.no> wrote= :
On 10/17/2014 12:02 AM, Bernard A= boba wrote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 A= nd
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



<= /div>--
Alex. Gouaillard= , PhD, PhD, MBA
-------------------------------------------------------= -----------------------------
CTO - Temasys Communications, S'= ;pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------= ------------------

  • =

_______________________________________________
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





--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------




--
=



--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------

--089e013c5d2cdc53cb0505cb049b-- From nobody Sun Oct 19 12:39:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEF71A6F6E for ; Sun, 19 Oct 2014 12:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7ORECBl1mPh for ; Sun, 19 Oct 2014 12:39:44 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CBC1A0101 for ; Sun, 19 Oct 2014 12:39:43 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id h11so7508816wiw.0 for ; Sun, 19 Oct 2014 12:39:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1VxyrPQfhsMdOxVb4pP1IsNGCxDzBoCzi/hKKnAD0UA=; b=CWUEgT+C4jZZIdCZpBLOgsz4UJ2tRY10cCBwafQ34fK9+N2sKN9DHmOFbDZvPvaLdK lA5+4jAT7v+XaXDvocyoL1c4xBErIJGpzW46DG+2VAKFNETUaUbxZkjfkwc+2bj1XAY5 bD4j3cXecO9XLmnSjrnmFWylT7W7yFKwKUyZTYbHkz2C0a3+b8IKpvzv0USvfKsEfSgi zwxdzJwCgw4z0JJGfpvZKhVj1U1P7SkRiuk48WHhq1VH3plrHQmEYiFRNVuSEaWJTPu3 lDFWubiHaF16fa3iSAVxQR2x3KVau3LnEzbvwANGjOZETc3BXo/d54TvepeQMw/7uVXZ yCFg== X-Gm-Message-State: ALoCoQkVh5yIzsY7de1d3MrGrf/0tocgq5jLxveahSD7MMLppWjF0gWO0sOUMAOxyBahLRkps2qs X-Received: by 10.194.236.200 with SMTP id uw8mr27809906wjc.50.1413747582411; Sun, 19 Oct 2014 12:39:42 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id fq1sm7162994wib.12.2014.10.19.12.39.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Oct 2014 12:39:41 -0700 (PDT) Message-ID: <54441380.6070900@jitsi.org> Date: Sun, 19 Oct 2014 21:39:44 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: RTCWEB Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oTzgI74woM296qCGKIlBWNG7FZM Subject: [rtcweb] Scheduling a separate slot for MTI VC Disuccions (Was: Plan for MTI video codec?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 19:39:46 -0000 Given how: a) a big number of people have indicated their concern that codec discussions would steal time away from other important topics that need to be progressed and how b) a second group of people seem to consider it important to have a discussion on developments around deployment, adoption and standardization of VP8 and H.264 then wouldn't it be reasonable to try and allocate an extra slot for an ad hoc meeting on the MTI Video Codec topic? Emil -- https://jitsi.org From nobody Sun Oct 19 13:31:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6141A6F8D for ; Sun, 19 Oct 2014 13:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZZ3ZIna9gzc for ; Sun, 19 Oct 2014 13:30:57 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727CE1A6F7E for ; Sun, 19 Oct 2014 13:30:56 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x13so4052815wgg.6 for ; Sun, 19 Oct 2014 13:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zv8ew6lqEWs/eGxwy75DhM6sSuY6M3ANt/DUK0OMDqc=; b=Tx5EeW4iDQIWEjTy1n08mPt7oCwkq3pK2RqCWWZThfpGwDLP+Nk7WEEliDVL+KUEq6 3nK1acgCqM53gYcwAsycxcAbhB/wz9t1RvQ+CgK3QTU8Of6Zu7ZlzqEpmW/m6P/Lp2G7 U+5TW+RS9krM4nK0gX7sELYKHsGLW1eQ8rYMx54OneuvhKLnERcoGjZT1+W/1h2hwNXp Y3BlAYW4CJitqnP3vqMrQT/FObQkDCMvLL0oDijHUI+76vFVFWWr0xE/TuW3mlQXacSZ Pxn4VLu/GwAqHQ9pZAna3nHAqeto3GpQZcDZtbdWZQZijYVYR1gfafTFVWC1iFP1O4nV 4ImA== X-Received: by 10.180.104.99 with SMTP id gd3mr5025023wib.10.1413750655037; Sun, 19 Oct 2014 13:30:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.134.196 with HTTP; Sun, 19 Oct 2014 13:30:34 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> From: Bernard Aboba Date: Sun, 19 Oct 2014 13:30:34 -0700 Message-ID: To: Alexandre GOUAILLARD Content-Type: multipart/alternative; boundary=f46d04428170983c440505cc793d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bxeislMgMXj-U2xC-GE5BOykxIU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 20:31:02 -0000 --f46d04428170983c440505cc793d Content-Type: text/plain; charset=UTF-8 Alex said: "I don't think apple will make a statement, but I remember reading that microsoft would support 264 (at least for media element playback) if it is available on the system. Bernard / shijun, any comment about which codec would be used for ORTC/WebRTC?" [BA] Microsoft, Apple, Cisco, Blackberry, Ericsson and others have previously co-authored an H.264 MTI proposal: https://tools.ietf.org/html/draft-burman-rtcweb-h264-proposal Even though that proposal expires next week, we still believe it is possible for an H.264 encoder/decoder to serve as a foundation for interoperability between independent implementations. However, choosing an MTI codec and specifying aspects of the codec is not enough. On wireless networks (bursty) packet loss is common, so it is important to specify transport aspects and robustness measures. This would include an MTI FEC scheme and bandwidth estimation techniques, as well as use of codec-specific feedback messages. In terms of what needs to be done, there is work needed on the rtp-usage document (such as addressing the MTI FEC scheme), draft-ietf-rtcweb-video, etc. Focussing on another MTI debate at this time could make it difficult to make major progress before IETF 92. If instead of tackling the hard problems, we spend our precious time on yet another MTI debate, this will not satisfy customers who have burned before. From past experience, they know that if interoperability issues are not addressed *early on*, patching things up after the fact can be difficult and time consuming. Yet that is *exactly* where we are headed. On Sun, Oct 19, 2014 at 11:46 AM, Alexandre GOUAILLARD < agouaillard@gmail.com> wrote: > @watson > > I would prefer the ISO process to see through before deciding. That's why > I keep bothering harald for news at every meeting ;-) If for any reason it > does not happen, we're back where we were when we did the last pool. > Nobody has sued .... yet, does not mean there is no IP risk. Actually, > there were at least 3 counts of nokia suing, but the three cases were > negotiated and the result is not available to the public. (here > > ) > > @jonathan > > Point taken, I hadn't thought about the implications of H264 hardware > acceleration. If indeed it leverages the need to get a license, that makes > the situation better. Would that be enough ...? We could map all the cases > and see what is left to be dealt with. In any case, deciding about 264 > without looking at 265 seems shortsighted, and I am not aware of any > binary, or hardware acceleration support available for 265 yet (even though > iPhone 6 claims to supports 265 acc in its specs, I'm not aware of API that > would allow native app to leverage this capacity). > > Correct me if I'm wrong or if I'm missing anything (anyone): > > -- desktop browsers -- > - firefox, let's assume the 264 binary is used. It also supports VP8. > - chrome on desktop supports vp8 but not 264 (as far as webrtc is > concerned, the media element supports 264 playback). > - what about IE / Safari ? I don't think apple will make a statement, but > I remember reading that microsoft would support 264 (at least for media > element playback) if it is available on the system. Bernard / shijun, any > comment about which codec would be used for ORTC/webRTC? > > -- mobile browsers -- > - no firefox on iOS. What about the android version, what does it support? > - chrome supports only VP8, and can't support webRTC on iOS anyway (even > though justin is working on a audio-only, API-injection-in-webkit solution). > - opera? > > -- mobile native -- > - iOS 8+ has system API for hw acc 264 > - android has system API for both hw acc 264 and VP8 (is it true?) > - the webrtc.org stack does not support 264 even though kaiduan die from > blackberry provided a patch for this > - the ericson's openwebrtc stack supports 264 in multiple ways (does it > support hw acc?) but lack support for Windows and data channel. > > -- Others -- > - lots of MCUs / SFUs / Gateways would need 264 in more cases than just > the interoperability between webrtc and SIP, and I'm not sure the cisco > binaries can be used there. > > On Mon, Oct 20, 2014 at 2:13 AM, Jonathan Rosenberg > wrote: > >> @Alexandre - you say "Today, nothing has changed with respect to those >> two items (even though providing open264 royalties and absorbing the >> license cost for some platforms might have been a set in the right >> direction). ". But, as you say, the availability of Firefox with H264 is a >> change (previously it was not yet available); the fact that Cisco has in >> fact fronted the cost is a change (at the last meeting some were skeptical >> this would happen, but it has). The other big news was IOS8, which now >> enables apps to access H264 and Apple pays the cost. Last time, the lack of >> a solution on IOS was a big deal. That is also now, no longer an issue. As >> such I think there are material changes. >> >> >> On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD < >> agouaillard@gmail.com> wrote: >> >>> @jonathan, >>> >>> while you are right and availability of 264 implementation or hardware >>> acceleration has improved, it has never been reported as a problem in the >>> previous pool by anyone. The 264 royalties, and the VP8 IP risks were, >>> AFAIR, the main reasons used by individuals to justify their positions. >>> Today, nothing has changed with respect to those two items (even though >>> providing open264 royalties and absorbing the license cost for some >>> platforms might have been a set in the right direction). This is why I >>> think the conditions are not met for a consensus to be reached. >>> >>> Alex. >>> >>> >>> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba >> > wrote: >>> >>>> "And its one of the issues holding up wider adoption of the technology" >>>> >>>> [BA] Specifying an MTI encoder/decoder is not sufficient for >>>> interoperability. It is also necessary to specify the transport in enough >>>> detail to allow independent implementations that interoperate well enough >>>> to be usable in a wide variety of scenarios, including wireless networks >>>> where loss is commonly experienced. >>>> >>>> We made the mistake of having an MTI discussion previously with not >>>> enough details on that subject, particularly with respect to H.264. >>>> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. >>>> >>>> So if we are to have the discussion again, it should occur in the >>>> context of detailed specifications and interoperability reports. >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg < >>>> jdrosen@jdrosen.net> wrote: >>>> >>>>> I'm in favor of taking another run at this. >>>>> >>>>> The working group has repeatedly said that an MTI codec is something >>>>> we need to produce. And its one of the issues holding up wider adoption of >>>>> the technology (not the only one for sure). >>>>> >>>>> And things have changed since the last meeting, a year ago now >>>>> (November in Vancouver). Cisco's open264 plugin shipped and now just >>>>> recently is integrated into Firefox. iOS8 shipped with APIs for H264. There >>>>> are other things worth noting. Will this change the minds of everyone? >>>>> Surely not. Will it sway enough for us to achieve rough consensus? Maybe. >>>>> IMHO - worth finding out. >>>>> >>>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < >>>>> agouaillard@gmail.com> wrote: >>>>> >>>>>> +1 to not having MTI codec discussion unless some progress has been >>>>>> made on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that >>>>>> there was no change on the members position. >>>>>> >>>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand < >>>>>> harald@alvestrand.no> wrote: >>>>>> >>>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>>>>> >>>>>>>> One thing we could do instead of wasting time on MTI is to actually >>>>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >>>>>>>> actually interoperate regardless of the codec. >>>>>>>> >>>>>>> >>>>>>> The big argument for an MTI is actually the one stated in -overview: >>>>>>> It guards against interoperability failure. >>>>>>> >>>>>>> I would like to have an ecosystem where one can field a box, connect >>>>>>> it to everything else, and run well for *some* level of "well" - and I >>>>>>> would prefer that ecosystem to be one where it's possible to field the box >>>>>>> without making prior arrangements with anyone about licenses. >>>>>>> >>>>>>> This argument hasn't changed one whit since last time we discussed >>>>>>> it. And I don't see much movement on the specifics of the proposals either. >>>>>>> >>>>>>> We'll have to interoperate well with the codecs we field. So using >>>>>>> some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 >>>>>>> isn't finished either. There's one sentence that needs to be removed.) >>>>>>> >>>>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >>>>>>> prefer to re-discuss based on the knowledge that some significant players >>>>>>> have actually changed their minds. >>>>>>> >>>>>>> At the moment, I don't see signs that any of the poll respondents >>>>>>> have said "I have changed my mind". >>>>>>> >>>>>>> Harald >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson < >>>>>>>>> martin.thomson@gmail.com> wrote: >>>>>>>>> >>>>>>>>> On 16 October 2014 14:17, Matthew Kaufman >>>>>>>>>> wrote: >>>>>>>>>> And that's because something substantive has changed, or simply >>>>>>>>>> because >>>>>>>>>> wasting the WG time on this again is more entertaining than >>>>>>>>>> actually >>>>>>>>>> finishing a specification that can be independently implemented >>>>>>>>>> by all >>>>>>>>>> browser vendors? (A specification that we are nowhere near >>>>>>>>>> having, as far as >>>>>>>>>> I can tell) >>>>>>>>>> >>>>>>>>> Personally, I've found the reprieve from this fight refreshing. >>>>>>>>> And >>>>>>>>> it would appear that we've made some real progress as a result. >>>>>>>>> I'd >>>>>>>>> suggest that if we don't have new information, we continue to spend >>>>>>>>> our time productively. If we can't find topics to occupy our >>>>>>>>> meeting >>>>>>>>> agenda time, then maybe we can free an agenda slot. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Alex. Gouaillard, PhD, PhD, MBA >>>>>> >>>>>> ------------------------------------------------------------------------------------ >>>>>> CTO - Temasys Communications, S'pore / Mountain View >>>>>> President - CoSMo Software, Cambridge, MA >>>>>> >>>>>> ------------------------------------------------------------------------------------ >>>>>> sg.linkedin.com/agouaillard >>>>>> >>>>>> - >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Jonathan Rosenberg, Ph.D. >>>>> jdrosen@jdrosen.net >>>>> http://www.jdrosen.net >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>>> >>>> >>> >>> >>> -- >>> Alex. Gouaillard, PhD, PhD, MBA >>> >>> ------------------------------------------------------------------------------------ >>> CTO - Temasys Communications, S'pore / Mountain View >>> President - CoSMo Software, Cambridge, MA >>> >>> ------------------------------------------------------------------------------------ >>> sg.linkedin.com/agouaillard >>> >>> - >>> >>> >> >> >> -- >> Jonathan Rosenberg, Ph.D. >> jdrosen@jdrosen.net >> http://www.jdrosen.net >> > > > > -- > Alex. Gouaillard, PhD, PhD, MBA > > ------------------------------------------------------------------------------------ > CTO - Temasys Communications, S'pore / Mountain View > President - CoSMo Software, Cambridge, MA > > ------------------------------------------------------------------------------------ > sg.linkedin.com/agouaillard > > - > > --f46d04428170983c440505cc793d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Alex said:

"I don't think apple will make a st= atement, but I remember reading that microsoft would support 264 (at least = for media element playback)=C2=A0if it is available on the system.= =C2=A0 Bernard / shijun, any comment about which codec would be used for OR= TC/WebRTC?"

[BA] Microsoft, Apple, Cisco, Blackberry, Ericsson and others= have previously co-authored an H.264 MTI proposal: https://tools.ietf.org/h= tml/draft-burman-rtcweb-h264-proposal

Even though that proposal expires next week,= we still believe it is possible for an H.264 encoder/decoder to serve as a= foundation for interoperability between independent implementations= . =C2=A0 However, choosing an MTI codec and specifying aspects of the codec= is not enough.=C2=A0 On wireless networks (bursty) packet loss is common, = so it is important to specify transport aspects and robustness measures.=C2= =A0 This would include an MTI FEC scheme and bandwidth estimation technique= s, as well as use of codec-specific feedback messages.=C2=A0

In terms of what needs to be done, there is work needed on th= e rtp-usage document (such as addressing the MTI FEC scheme), =C2=A0draft-i= etf-rtcweb-video, etc.=C2=A0 Focussing on another MTI debate at this time c= ould make it difficult to make major progress before IETF 92.=C2=A0=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

If instead of tackling the hard problems, we spend our precio= us time on yet another MTI debate, this will not satisfy customers who have= burned before.=C2=A0 From past experience, they know that if interoperabil= ity issues are not addressed *early on*, patching things up after the fact = can be difficult and time consuming.=C2=A0 Yet that is *exactly* where we a= re headed.=C2=A0


On Sun, Oct 19, 2014 at 11:46 AM, Alexandre GOUAILLARD <ago= uaillard@gmail.com> wrote:
=
@watson

I would prefer the ISO process = to see through before deciding. That's why I keep bothering harald for = news at every meeting ;-) If for any reason it does not happen, we're b= ack where we were when we did the last pool.
Nobody has sued ....= yet, does not mean there is no IP risk. Actually, there were at least 3 co= unts of nokia suing, but the three cases were negotiated and the result is = not available to the public. (here)

@jonathan

Point taken, I ha= dn't thought about the implications of H264 hardware acceleration. If i= ndeed it leverages the need to get a license, that makes the situation bett= er. Would that be enough ...? We could map all the cases and see what is le= ft to be dealt with. In any case, deciding about 264 without looking at 265= seems shortsighted, and I am not aware of any binary, or hardware accelera= tion support available for 265 yet (even though iPhone 6 claims to supports= 265 acc in its specs, I'm not aware of API that would allow native app= to leverage this capacity).=C2=A0

Correct me if I= 'm wrong or if I'm missing anything (anyone):

-- desktop browsers --
- firefox, let's assume the 26= 4 binary is used. It also supports VP8.
- chrome on desktop suppo= rts vp8 but not 264 (as far as webrtc is concerned, the media element suppo= rts 264 playback).
- what about IE / Safari ? I don't think a= pple will make a statement, but I remember reading that microsoft would sup= port 264 (at least for media element playback) if it is available on the sy= stem. Bernard / shijun, any comment about which codec would be used for ORT= C/webRTC?

-- mobile browsers --
- no fir= efox on iOS. What about the android version, what does it support?
- chrome supports only VP8, and can't support webRTC on iOS anyway (e= ven though justin is working on a audio-only, API-injection-in-webkit solut= ion).
- opera?

-- mobile native --
=
- iOS 8+ has system API for hw acc 264
- android has system = API for both hw acc 264 and VP8 (is it true?)
- the webrtc.org stack does not support 26= 4 even though kaiduan die from blackberry provided a patch for this
- the ericson's openwebrtc stack supports 264 in multiple ways (does= it support hw acc?) but lack support for Windows and data channel.

-- Others --
- lots of MCUs / SFUs / Gateways w= ould need 264 in more cases than just the interoperability between webrtc a= nd SIP, and I'm not sure the cisco binaries can be used there.=C2=A0

On Mon, Oct 20, 2014 at 2:13 AM, Jonathan R= osenberg <jdrosen@jdrosen.net> wrote:
@Alexandre - you say "Today, nothing has changed with = respect to those two items (even though providing open264 royalties and abs= orbing the license cost for some platforms might have been a set in the rig= ht direction).=C2=A0". But, as you say, the availability of Firefox wi= th H264 is a change (previously it was not yet available); the fact that Ci= sco has in fact fronted the cost is a change (at the last meeting some were= skeptical this would happen, but it has). The other big news was IOS8, whi= ch now enables apps to access H264 and Apple pays the cost. Last time, the = lack of a solution on IOS was a big deal. That is also now, no longer an is= sue. As such I think there are material changes.


On Sun, Oct 19= , 2014 at 12:13 PM, Alexandre GOUAILLARD <agouaillard@gmail.com>= ; wrote:
@jonatha= n,

while you are right and availability of 264 implement= ation or hardware acceleration has improved, it has never been reported as = a problem in the previous pool by anyone. The 264 royalties, and the VP8 IP= risks were, AFAIR, the main reasons used by individuals to justify their p= ositions. Today, nothing has changed with respect to those two items (even = though providing open264 royalties and absorbing the license cost for some = platforms might have been a set in the right direction). This is why I thin= k the conditions are not met for a consensus to be reached.

<= /div>
Alex.


On Sun, Oct 19, 2014 at 11:43 PM, Bernar= d Aboba <bernard.aboba@gmail.com> wrote:
"And its one of the issues= holding up wider adoption of the technology"

[BA] Specifying an MTI encoder/decoder is not sufficient for interoperabi= lity.=C2=A0 It is also necessary to specify the transport in enough detail = to allow independent implementations that interoperate well enough to be us= able in a wide variety of scenarios, including wireless networks where loss= is commonly experienced. =C2=A0

We made the mista= ke of having an MTI discussion previously with not enough details on that s= ubject, particularly with respect to H.264. draft-ietf-rtcweb-video section= s 4.2 - 4.4 remain sketchy at best. =C2=A0

So if w= e are to have the discussion again, it should occur in the context of detai= led specifications and interoperability reports.

= =C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM,= Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
I'm in favor of taking anothe= r run at this.

The working group has repeatedly said tha= t an MTI codec is something we need to produce. And its one of the issues h= olding up wider adoption of the technology (not the only one for sure).

And things have changed since the last meeting, a yea= r ago now (November in Vancouver). Cisco's open264 plugin shipped and n= ow just recently is integrated into Firefox. iOS8 shipped with APIs for H26= 4. There are other things worth noting. Will this change the minds of every= one? Surely not. Will it sway enough for us to achieve rough consensus? May= be. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:08 PM, Alexandr= e GOUAILLARD <agouaillard@gmail.com> wrote:
+1 to not having MTI codec discussio= n unless some progress has been made on VP8 at MPEG.=C2=A0Any news on that?= I'm sharing harald's =C2=A0feeling that there was no change on the= members position.=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <= span dir=3D"ltr"><harald@alvestrand.no> wrote:
On 10/17/2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 A= nd
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



<= /div>--
Alex. Gouaillard= , PhD, PhD, MBA
-------------------------------------------------------= -----------------------------
CTO - Temasys Communications, S'= ;pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------= ------------------

  • =

_______________________________________________
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





--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------




--
=


--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------


--f46d04428170983c440505cc793d-- From nobody Sun Oct 19 13:38:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783431A6F7E for ; Sun, 19 Oct 2014 13:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w63q7E9jhVIu for ; Sun, 19 Oct 2014 13:38:10 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id A769A1A1B86 for ; Sun, 19 Oct 2014 13:38:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5CD607C4E70 for ; Sun, 19 Oct 2014 22:38:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyVZyvoY6B55 for ; Sun, 19 Oct 2014 22:38:04 +0200 (CEST) Received: from [10.121.41.131] (65.129-14-84.ripe.coltfrance.com [84.14.129.65]) by mork.alvestrand.no (Postfix) with ESMTPSA id 226897C41CE for ; Sun, 19 Oct 2014 22:38:02 +0200 (CEST) Message-ID: <54442128.6070009@alvestrand.no> Date: Sun, 19 Oct 2014 22:38:00 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020705070909080705050003" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nuB0OnwFlpUmRlfpL_-LJ11vn04 Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 20:38:14 -0000 This is a multi-part message in MIME format. --------------020705070909080705050003 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/19/2014 05:43 PM, Bernard Aboba wrote: > "And its one of the issues holding up wider adoption of the technology" > > [BA] Specifying an MTI encoder/decoder is not sufficient for > interoperability. It is also necessary to specify the transport in > enough detail to allow independent implementations that interoperate > well enough to be usable in a wide variety of scenarios, including > wireless networks where loss is commonly experienced. Bernard, I think this is, to a large degree, codec independent. We have demonstrated interoperability on VP8 between Firefox and Chrome, and usage of various mechanisms for congestion control and repair of packet loss being applied in live services. So it can't be all bad..... > > We made the mistake of having an MTI discussion previously with not > enough details on that subject, particularly with respect to H.264. > draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > > So if we are to have the discussion again, it should occur in the > context of detailed specifications and interoperability reports. > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > > wrote: > > I'm in favor of taking another run at this. > > The working group has repeatedly said that an MTI codec is > something we need to produce. And its one of the issues holding up > wider adoption of the technology (not the only one for sure). > > And things have changed since the last meeting, a year ago now > (November in Vancouver). Cisco's open264 plugin shipped and now > just recently is integrated into Firefox. iOS8 shipped with APIs > for H264. There are other things worth noting. Will this change > the minds of everyone? Surely not. Will it sway enough for us to > achieve rough consensus? Maybe. IMHO - worth finding out. > > On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD > > wrote: > > +1 to not having MTI codec discussion unless some progress has > been made on VP8 at MPEG. Any news on that? I'm sharing > harald's feeling that there was no change on the members > position. > > On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > > wrote: > > On 10/17/2014 12:02 AM, Bernard Aboba wrote: > > One thing we could do instead of wasting time on MTI > is to actually make progress on Sections 4.2 - 4.4 of > draft-IETF-RTCWEB-video, so we could actually > interoperate regardless of the codec. > > > The big argument for an MTI is actually the one stated in > -overview: It guards against interoperability failure. > > I would like to have an ecosystem where one can field a > box, connect it to everything else, and run well for > *some* level of "well" - and I would prefer that ecosystem > to be one where it's possible to field the box without > making prior arrangements with anyone about licenses. > > This argument hasn't changed one whit since last time we > discussed it. And I don't see much movement on the > specifics of the proposals either. > > We'll have to interoperate well with the codecs we field. > So using some time to discuss draft-ietf-rtcweb-video > seems to make sense. (And 4.1 isn't finished either. > There's one sentence that needs to be removed.) > > I wouldn't say I'd be happy to not discuss this in > Honolulu. But I'd prefer to re-discuss based on the > knowledge that some significant players have actually > changed their minds. > > At the moment, I don't see signs that any of the poll > respondents have said "I have changed my mind". > > Harald > > > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > > wrote: > > On 16 October 2014 14:17, Matthew Kaufman > > wrote: > And that's because something substantive has > changed, or simply because > wasting the WG time on this again is more > entertaining than actually > finishing a specification that can be > independently implemented by all > browser vendors? (A specification that we are > nowhere near having, as far as > I can tell) > > Personally, I've found the reprieve from this > fight refreshing. And > it would appear that we've made some real progress > as a result. I'd > suggest that if we don't have new information, we > continue to spend > our time productively. If we can't find topics to > occupy our meeting > agenda time, then maybe we can free an agenda slot. > > _______________________________________________ > 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 > > > > > -- > Alex. Gouaillard, PhD, PhD, MBA > ------------------------------------------------------------------------------------ > CTO - Temasys Communications, S'pore / Mountain View > President - CoSMo Software, Cambridge, MA > ------------------------------------------------------------------------------------ > sg.linkedin.com/agouaillard > > * > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > _______________________________________________ > 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 -- Surveillance is pervasive. Go Dark. --------------020705070909080705050003 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/19/2014 05:43 PM, Bernard Aboba wrote:
"And its one of the issues holding up wider adoption of the technology"

[BA] Specifying an MTI encoder/decoder is not sufficient for interoperability.  It is also necessary to specify the transport in enough detail to allow independent implementations that interoperate well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienced. 

Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, and usage of various mechanisms for congestion control and repair of packet loss being applied in live services.

So it can't be all bad.....


We made the mistake of having an MTI discussion previously with not enough details on that subject, particularly with respect to H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.  

So if we are to have the discussion again, it should occur in the context of detailed specifications and interoperability reports.

 

 

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
I'm in favor of taking another run at this.

The working group has repeatedly said that an MTI codec is something we need to produce. And its one of the issues holding up wider adoption of the technology (not the only one for sure).

And things have changed since the last meeting, a year ago now (November in Vancouver). Cisco's open264 plugin shipped and now just recently is integrated into Firefox. iOS8 shipped with APIs for H264. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:
+1 to not having MTI codec discussion unless some progress has been made on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling that there was no change on the members position. 

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 10/17/2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It guards against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to everything else, and run well for *some* level of "well" - and I would prefer that ecosystem to be one where it's possible to field the box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. And I don't see much movement on the specifics of the proposals either.

We'll have to interoperate well with the codecs we field. So using some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't finished either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer to re-discuss based on the knowledge that some significant players have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far as
I can tell)
Personally, I've found the reprieve from this fight refreshing.  And
it would appear that we've made some real progress as a result.  I'd
suggest that if we don't have new information, we continue to spend
our time productively.  If we can't find topics to occupy our meeting
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------


_______________________________________________
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



-- 
Surveillance is pervasive. Go Dark.
--------------020705070909080705050003-- From nobody Sun Oct 19 14:29:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AA01A00BB for ; Sun, 19 Oct 2014 14:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp4d5sDLQxzO for ; Sun, 19 Oct 2014 14:29:27 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A4F1A01FA for ; Sun, 19 Oct 2014 14:29:27 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id fb4so4827463wid.4 for ; Sun, 19 Oct 2014 14:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=L2Her3HHpv1t2HRjSfJ/Vg5iRj4NPxDX1WdpW+Foi0c=; b=T/MPSpNy6cr2mP6V9JAWPYu6AM+ln+MojLBnMQhdXbYD3jZJ/DSZ8WZsXlgVE9LyCP n3IzU6HM4pwutSCQVIgugxDpODqWAXHksBnb9JlPp19gNQmdkolDNUNVXnK/ETelazIU ishUIQR2wJz/AhCzXdPTSX9H0KTqUcFwrEwplyCulK9/shBlColJFPYJTQkr1uVHWQNQ yhe1RGuDM6F+oLJJCiLK5+5P0g4S7QleiQ6vUtf3vAB7r7w1yPdbe+BQnEoRd9cgQbEC JaBT0m3XDyTvt5Wp26rHYCteZ99poa0XFcQvgC8FLcjWJhp1SlN8dT2tnvCT4KBWNdwZ NaHw== X-Received: by 10.180.218.136 with SMTP id pg8mr14671408wic.37.1413754165983; Sun, 19 Oct 2014 14:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.134.196 with HTTP; Sun, 19 Oct 2014 14:29:05 -0700 (PDT) In-Reply-To: <54442128.6070009@alvestrand.no> References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> From: Bernard Aboba Date: Sun, 19 Oct 2014 14:29:05 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1134d9b2dcfedd0505cd4aba Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JyNAhnDvrDmAQ0BnjPBp-hbwxiQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 21:29:31 -0000 --001a1134d9b2dcfedd0505cd4aba Content-Type: text/plain; charset=UTF-8 Harald said: "Bernard, I think this is, to a large degree, codec independent. We have demonstrated interoperability on VP8 between Firefox and Chrome, and usage of various mechanisms for congestion control and repair of packet loss being applied in live services. So it can't be all bad....." [BA] I agree that the lack of interoperability is largely "codec independent": that is, implementations based on different mechanisms for congestion control, repair, etc. will exhibit interoperability problems, regardless of the codec chosen. The real test for RTCWEB will be to move beyond "interoperability of implementations sharing source code" to "interoperability of independent implementations, based on open standards". On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand wrote: > On 10/19/2014 05:43 PM, Bernard Aboba wrote: > > "And its one of the issues holding up wider adoption of the technology" > > [BA] Specifying an MTI encoder/decoder is not sufficient for > interoperability. It is also necessary to specify the transport in enough > detail to allow independent implementations that interoperate well enough > to be usable in a wide variety of scenarios, including wireless networks > where loss is commonly experienced. > > > Bernard, > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of packet > loss being applied in live services. > > So it can't be all bad..... > > > > We made the mistake of having an MTI discussion previously with not > enough details on that subject, particularly with respect to H.264. > draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > > So if we are to have the discussion again, it should occur in the > context of detailed specifications and interoperability reports. > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: > >> I'm in favor of taking another run at this. >> >> The working group has repeatedly said that an MTI codec is something we >> need to produce. And its one of the issues holding up wider adoption of the >> technology (not the only one for sure). >> >> And things have changed since the last meeting, a year ago now >> (November in Vancouver). Cisco's open264 plugin shipped and now just >> recently is integrated into Firefox. iOS8 shipped with APIs for H264. There >> are other things worth noting. Will this change the minds of everyone? >> Surely not. Will it sway enough for us to achieve rough consensus? Maybe. >> IMHO - worth finding out. >> >> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < >> agouaillard@gmail.com> wrote: >> >>> +1 to not having MTI codec discussion unless some progress has been made >>> on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that there >>> was no change on the members position. >>> >>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand >> > wrote: >>> >>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>> >>>>> One thing we could do instead of wasting time on MTI is to actually >>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >>>>> actually interoperate regardless of the codec. >>>>> >>>> >>>> The big argument for an MTI is actually the one stated in -overview: >>>> It guards against interoperability failure. >>>> >>>> I would like to have an ecosystem where one can field a box, connect it >>>> to everything else, and run well for *some* level of "well" - and I would >>>> prefer that ecosystem to be one where it's possible to field the box >>>> without making prior arrangements with anyone about licenses. >>>> >>>> This argument hasn't changed one whit since last time we discussed it. >>>> And I don't see much movement on the specifics of the proposals either. >>>> >>>> We'll have to interoperate well with the codecs we field. So using some >>>> time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't >>>> finished either. There's one sentence that needs to be removed.) >>>> >>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >>>> prefer to re-discuss based on the knowledge that some significant players >>>> have actually changed their minds. >>>> >>>> At the moment, I don't see signs that any of the poll respondents have >>>> said "I have changed my mind". >>>> >>>> Harald >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson >>>>>> wrote: >>>>>> >>>>>> On 16 October 2014 14:17, Matthew Kaufman >>>>>>> wrote: >>>>>>> And that's because something substantive has changed, or simply >>>>>>> because >>>>>>> wasting the WG time on this again is more entertaining than actually >>>>>>> finishing a specification that can be independently implemented by >>>>>>> all >>>>>>> browser vendors? (A specification that we are nowhere near having, >>>>>>> as far as >>>>>>> I can tell) >>>>>>> >>>>>> Personally, I've found the reprieve from this fight refreshing. And >>>>>> it would appear that we've made some real progress as a result. I'd >>>>>> suggest that if we don't have new information, we continue to spend >>>>>> our time productively. If we can't find topics to occupy our meeting >>>>>> agenda time, then maybe we can free an agenda slot. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> Alex. Gouaillard, PhD, PhD, MBA >>> >>> ------------------------------------------------------------------------------------ >>> CTO - Temasys Communications, S'pore / Mountain View >>> President - CoSMo Software, Cambridge, MA >>> >>> ------------------------------------------------------------------------------------ >>> sg.linkedin.com/agouaillard >>> >>> - >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> >> >> -- >> Jonathan Rosenberg, Ph.D. >> jdrosen@jdrosen.net >> http://www.jdrosen.net >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1134d9b2dcfedd0505cd4aba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Harald said:=C2=A0

"Bernard,

I think this is, to a large degree, code= c independent.

We have demonstrated inter= operability on VP8 between Firefox and Chrome, and usage of various mechani= sms for congestion control and repair of packet loss being applied in live = services.
<= br style=3D"font-family:arial,sans-serif;font-size:13px">
So it can't be all bad= ....."

[BA] =C2=A0I agree that the lac= k of interoperability is largely "codec independent": =C2=A0 that= is, implementations based on different mechanisms for congestion control, = repair, etc. will exhibit interoperability problems, regardless of the code= c chosen. =C2=A0 The real test for RTCWEB will be to move beyond "inte= roperability of implementations sharing source code" =C2=A0to "in= teroperability of independent implementations, based on open standards"= ;. =C2=A0=C2=A0

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand <harald@al= vestrand.no> wrote:
=20 =20 =20
On 10/19/2014 05:43 PM, Bernard Aboba wrote:
"And its one of the issues holding up wider adoption of the technology"

[BA] Specifying an MTI encoder/decoder is not sufficient for interoperability.=C2=A0 It is also necessary to specify the transport in enough detail to allow independent implementations that interoperate well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienced.=C2=A0

Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, and usage of various mechanisms for congestion control and repair of packet loss being applied in live services.

So it can't be all bad.....



We made the mistake of having an MTI discussion previously with not enough details on that subject, particularly with respect to H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. =C2=A0

So if we are to have the discussion again, it should occur in the context of detailed specifications and interoperability reports.

=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:<= br>
I'm in favor of taking another run at this= .

The working group has repeatedly said that an MTI codec is something we need to produce. And its one of the issues holding up wider adoption of the technology (not the only one for sure).

And things have changed since the last meeting, a year ago now (November in Vancouver). Cisco's open264 plugin shipped and now just recently is integrated into Firefox. iOS8 shipped with APIs for H264. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:
+1 to not having MTI codec discussion unless some progress has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing harald's =C2=A0feeling that there was no change= on the members position.=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <hara= ld@alvestrand.no> wrote:
On 10/17/2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It guards against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to everything else, and run well for *some* level of "well" - and I would pre= fer that ecosystem to be one where it's possible to field the box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. And I don't see much movement on the specific= s of the proposals either.

We'll have to interoperate well with th= e codecs we field. So using some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't finished either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefe= r to re-discuss based on the knowledge that some significant players have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have said "= ;I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com&= gt; wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far as I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 And
it would appear that we've made some real progress as a result.=C2= =A0 I'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meeting
agenda time, then maybe we can free an agenda slot.

___________________________________= ____________
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/r= tcweb



--
Alex. Gouaillard, PhD, PhD, MBA
----------------------------------------= --------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
----------------------------------------= --------------------------------------------


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




--

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




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



--=20
Surveillance is pervasive. Go Dark.

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


--001a1134d9b2dcfedd0505cd4aba-- From nobody Sun Oct 19 14:38:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21921A00A3 for ; Sun, 19 Oct 2014 14:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIiXlPVnB-OH for ; Sun, 19 Oct 2014 14:38:29 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7CE1A003B for ; Sun, 19 Oct 2014 14:38:29 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id ar1so3619836iec.38 for ; Sun, 19 Oct 2014 14:38:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KBpSTPDjuvSy6rMlA4/it9NaQVhv+PmsOZZI7ezlHj4=; b=OhG3ZCZKnAsCE+jULINTz/qeVL8tDYspOVwrNyrjj9OYgKcknutwHBttWzX1Dj1iZQ 7Q3IK+PvFqJmlISC92abjGgilZWQB4gDWs2b/SmD+xrLSAYnwDSg9688ljjI9BgnN0Pt yg+FFPovQDKe468YS/aidGYCKe498ViPhJ4tMDTS2m7ViDjK8dX1a15DZZwDV2yreEjE crPqyT3CFD3ltLjgR1+jrtP22p3w6EpZTp7tlbkMaaTRpRdiTGJW3Csf0j5KgyT5Bf2K YQrQP76fyX5UVt3oEkZnL6HpOjIxHOLYdR6mR8jafOd+exPXnFa2psuu2eY50L7IogLG mW1A== X-Gm-Message-State: ALoCoQkWtoVpEh0+dxOlBYt7R+B3P7uBM7022fPQ6y0KDqMBf5T/lP9ZsVoWAG39cnOWaC8WO3cY X-Received: by 10.50.164.233 with SMTP id yt9mr14085137igb.2.1413754707827; Sun, 19 Oct 2014 14:38:27 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id x193sm3670902iod.17.2014.10.19.14.38.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Oct 2014 14:38:27 -0700 (PDT) Message-ID: <54442F52.3090608@andyet.net> Date: Sun, 19 Oct 2014 15:38:26 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Hardie , "rtcweb@ietf.org" , Sean Turner , Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2PtRFwGYXYvkyOzIVRBqO8QIXvs Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 21:38:32 -0000 On 10/16/14, 11:10 AM, Ted Hardie wrote: > During this morning chairs call, we discussed the agenda for the > upcoming meeting. The two big items are JSEP and the video codec > discussion, and our current thought is to have the JSEP discussion on > Monday and the video codec discussion on Thursday. As far as I can see, the temper of the list has been that it would be premature and a waste of energy to discuss the video codec topic at IETF 91. Do the chairs see things differently? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sun Oct 19 18:10:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0F81A1A74 for ; Sun, 19 Oct 2014 18:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NhJDIgG3yhg for ; Sun, 19 Oct 2014 18:10:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:734]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E16A1A1A03 for ; Sun, 19 Oct 2014 18:10:31 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB411.namprd07.prod.outlook.com (10.141.73.154) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 01:10:06 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Mon, 20 Oct 2014 01:10:03 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.72]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.72]) with mapi id 15.00.1049.012; Mon, 20 Oct 2014 01:10:03 +0000 From: Stephan Wenger To: Watson Ladd , Alexandre GOUAILLARD Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHOrixjgMwfvYrSbUqrcWE5foJ0c5wzqjdjgAAvKoCAAddnAIAAAwiAgAAJmQCAAQDrgIACFIiAgAEvmwCAAAgMAIAACFqAgAAAiICAACAFgA== Date: Mon, 20 Oct 2014 01:10:01 +0000 Message-ID: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR07MB363;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03706074BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(199003)(24454002)(51704005)(377454003)(189002)(479174003)(95666004)(19580405001)(120916001)(16601075003)(99286002)(21056001)(93886004)(85306004)(20776003)(107046002)(46102003)(15202345003)(2656002)(76482002)(19580395003)(92726001)(66066001)(99396003)(31966008)(77096002)(54356999)(86362001)(97736003)(80022003)(101416001)(92566001)(122556002)(50986999)(64706001)(85852003)(40100003)(76176999)(87936001)(106356001)(106116001)(36756003)(4396001)(15975445006)(105586002)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR07MB363; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR07MB411; X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oHE7CWM533ljnalVk1Gff00Bn-4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 01:10:36 -0000 Hi, On 10/19/14, 9:15 AM, "Watson Ladd" wrote: >On Sun, Oct 19, 2014 at 9:13 AM, Alexandre GOUAILLARD > wrote: >> @jonathan, >> >> while you are right and availability of 264 implementation or hardware >> acceleration has improved, it has never been reported as a problem in >>the >> previous pool by anyone. The 264 royalties, and the VP8 IP risks were, >> AFAIR, the main reasons used by individuals to justify their positions. >> Today, nothing has changed with respect to those two items (even though >> providing open264 royalties and absorbing the license cost for some >> platforms might have been a set in the right direction). This is why I >>think >> the conditions are not met for a consensus to be reached. > >But now VP8 is going through ISO, ... and is is DIS ballot. Few projects in ISO get stopped at that stage. To me, it=B9s pretty clear that VP8 will have an ISO/IEC blessing within a year or two. Without substantial technical changes. Given the very limited participation in the relevant subgroup in MPEG, it=B9s unclear to m= e what good that will do, though. >and the people claiming patents on >VP8 have had time to sue, and haven't. That=B9s factually incorrect. To the best of my knowledge, what would be factually correct is this: in two cases, companies have been sued over patents allegedly reading on VP8 in the context of the wider =B3smartphone wars=B2 lawsuits, and the defendants have won non-infringement rulings in the first instance (though, last I looked, appeals were pending in both cases). At least one other case was settled on undisclosed terms. Some of these cases were widely reported in the press, others are a little bit harder to find without access to legal search tools. >That's evidence that some >concerns are overblown. And that depends on your viewpoint. Stephan > >> >> Alex. >> >> >> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba >> >> wrote: >>> >>> "And its one of the issues holding up wider adoption of the technology" >>> >>> [BA] Specifying an MTI encoder/decoder is not sufficient for >>> interoperability. It is also necessary to specify the transport in >>>enough >>> detail to allow independent implementations that interoperate well >>>enough to >>> be usable in a wide variety of scenarios, including wireless networks >>>where >>> loss is commonly experienced. >>> >>> We made the mistake of having an MTI discussion previously with not >>>enough >>> details on that subject, particularly with respect to H.264. >>> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. >>> >>> So if we are to have the discussion again, it should occur in the >>>context >>> of detailed specifications and interoperability reports. >>> >>> >>> >>> >>> >>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg >>> >>> wrote: >>>> >>>> I'm in favor of taking another run at this. >>>> >>>> The working group has repeatedly said that an MTI codec is something >>>>we >>>> need to produce. And its one of the issues holding up wider adoption >>>>of the >>>> technology (not the only one for sure). >>>> >>>> And things have changed since the last meeting, a year ago now >>>>(November >>>> in Vancouver). Cisco's open264 plugin shipped and now just recently is >>>> integrated into Firefox. iOS8 shipped with APIs for H264. There are >>>>other >>>> things worth noting. Will this change the minds of everyone? Surely >>>>not. >>>> Will it sway enough for us to achieve rough consensus? Maybe. IMHO - >>>>worth >>>> finding out. >>>> >>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD >>>> wrote: >>>>> >>>>> +1 to not having MTI codec discussion unless some progress has been >>>>>made >>>>> on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that >>>>>there >>>>> was no change on the members position. >>>>> >>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand >>>>> wrote: >>>>>> >>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>>>>> >>>>>>> One thing we could do instead of wasting time on MTI is to actually >>>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so >>>>>>>we could >>>>>>> actually interoperate regardless of the codec. >>>>>> >>>>>> >>>>>> The big argument for an MTI is actually the one stated in >>>>>>-overview: It >>>>>> guards against interoperability failure. >>>>>> >>>>>> I would like to have an ecosystem where one can field a box, >>>>>>connect it >>>>>> to everything else, and run well for *some* level of "well" - and I >>>>>>would >>>>>> prefer that ecosystem to be one where it's possible to field the >>>>>>box without >>>>>> making prior arrangements with anyone about licenses. >>>>>> >>>>>> This argument hasn't changed one whit since last time we discussed >>>>>>it. >>>>>> And I don't see much movement on the specifics of the proposals >>>>>>either. >>>>>> >>>>>> We'll have to interoperate well with the codecs we field. So using >>>>>>some >>>>>> time to discuss draft-ietf-rtcweb-video seems to make sense. (And >>>>>>4.1 isn't >>>>>> finished either. There's one sentence that needs to be removed.) >>>>>> >>>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >>>>>> prefer to re-discuss based on the knowledge that some significant >>>>>>players >>>>>> have actually changed their minds. >>>>>> >>>>>> At the moment, I don't see signs that any of the poll respondents >>>>>>have >>>>>> said "I have changed my mind". >>>>>> >>>>>> Harald >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 16 October 2014 14:17, Matthew Kaufman >>>>>>>>> wrote: >>>>>>>>> And that's because something substantive has changed, or simply >>>>>>>>> because >>>>>>>>> wasting the WG time on this again is more entertaining than >>>>>>>>>actually >>>>>>>>> finishing a specification that can be independently implemented >>>>>>>>>by >>>>>>>>> all >>>>>>>>> browser vendors? (A specification that we are nowhere near >>>>>>>>>having, >>>>>>>>> as far as >>>>>>>>> I can tell) >>>>>>>> >>>>>>>> Personally, I've found the reprieve from this fight refreshing. >>>>>>>>And >>>>>>>> it would appear that we've made some real progress as a result. >>>>>>>>I'd >>>>>>>> suggest that if we don't have new information, we continue to >>>>>>>>spend >>>>>>>> our time productively. If we can't find topics to occupy our >>>>>>>>meeting >>>>>>>> agenda time, then maybe we can free an agenda slot. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Alex. Gouaillard, PhD, PhD, MBA >>>>> >>>>>=20 >>>>>---------------------------------------------------------------------- >>>>>-------------- >>>>> CTO - Temasys Communications, S'pore / Mountain View >>>>> President - CoSMo Software, Cambridge, MA >>>>> >>>>>=20 >>>>>---------------------------------------------------------------------- >>>>>-------------- >>>>> sg.linkedin.com/agouaillard >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>> >>>> >>>> >>>> -- >>>> Jonathan Rosenberg, Ph.D. >>>> jdrosen@jdrosen.net >>>> http://www.jdrosen.net >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >> >> >> >> -- >> Alex. Gouaillard, PhD, PhD, MBA >>=20 >>------------------------------------------------------------------------- >>----------- >> CTO - Temasys Communications, S'pore / Mountain View >> President - CoSMo Software, Cambridge, MA >>=20 >>------------------------------------------------------------------------- >>----------- >> sg.linkedin.com/agouaillard >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > >--=20 >"Those who would give up Essential Liberty to purchase a little >Temporary Safety deserve neither Liberty nor Safety." >-- Benjamin Franklin > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Oct 19 18:20:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4474C1A1A82 for ; Sun, 19 Oct 2014 18:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClLdi_wTx5Mr for ; Sun, 19 Oct 2014 18:20:07 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 817D61A1A7E for ; Sun, 19 Oct 2014 18:20:07 -0700 (PDT) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 19 Oct 2014 18:20:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208,217";a="402688888" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by FMSMGA003.fm.intel.com with ESMTP; 19 Oct 2014 18:12:36 -0700 Received: from orsmsx158.amr.corp.intel.com ([169.254.10.242]) by ORSMSX109.amr.corp.intel.com ([169.254.2.27]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 18:20:05 -0700 From: "Cavigioli, Chris" To: Harald Alvestrand , Bernard Aboba Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP69ySvH0vdbAWv0eULyOYAeS/S5w4ZQqA//+vamA= Date: Mon, 20 Oct 2014 01:20:04 +0000 Message-ID: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD2400622F1ORSMSX158amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UNKWn5xIv18xR6bB984Zw2tUDWE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 01:20:13 -0000 --_000_E36D1A4AE0B6AA4091F1728D584A6AD2400622F1ORSMSX158amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFyYWxkIHNhaWQ6DQrigJxXZSBtYWRlIHRoZSBtaXN0YWtlIG9mIGhhdmluZyBhbiBNVEkgZGlz Y3Vzc2lvbiBwcmV2aW91c2x5IHdpdGggbm90IGVub3VnaCBkZXRhaWxzIG9uIHRoYXQgc3ViamVj dOKApuKAnQ0KDQpXZSBkaWRu4oCZdCBoYXZlIHF1YW50aXRhdGl2ZSBkYXRhIGVhcmxpZXIgZm9y IGEgZGF0YS1kcml2ZW4gZGVjaXNpb24uICBGdXR1cmUgV2ViIOKAkyBMVEUgaW50ZXJvcCBpcyBp bXBvcnRhbnQuICBBIGdyb3VwIG9mIHVzIGluIEdTTUEgaGF2ZSBiZWVuIGxvb2tpbmcgYXQgV2Vi UlRDIGludGVyb3Agd2l0aCBMVEUgKHdoZXJlIDNHUFAgLyBHU01BIGRlZmluZWQgSU1TLWJhc2Vk IHZvaWNlL3ZpZGVvL21lc3NhZ2luZyksIHNwZWNpZmljYWxseSBsb29raW5nIGF0IHVzZXIgZXhw ZXJpZW5jZSBpbXBhY3Qgb2YgbGF0ZW5jeSBpbnRyb2R1Y2VkIGJ5IGFkZGVkIGluLW5ldHdvcmsg dHJhbnNjb2RpbmcuICBHU01BIGhhcyBhcHByb3ZlZCB0aGUgd2hpdGVwYXBlciBhbmQgaXQgaXMg YmVpbmcgcHJlcGFyZWQgZm9yIHB1YmxpYyBkaXN0cmlidXRpb24uDQoNCldlYlJUQyDigJMgTFRF IHRyYW5zY29kaW5nIGlzIG5vdyBNQU5EQVRPUlkgYmVjYXVzZSBvZiDigJxXZWJSVEMgQXVkaW8g Q29kZWMgYW5kIFByb2Nlc3NpbmcgUmVxdWlyZW1lbnRz4oCdLiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0wNSwgd2hlcmUgTVRJIGF1ZGlvIGNvZGVj cyBpbiBXZWJSVEMgYW5kIGluIExURSBhcmUgZGlzc2ltaWxhci4gIFRodXMsIFJFR0FSRExFU1Mg b2YgdGhlIHZpZGVvIGNvZGVjcywgdGhlcmUgaXMgYWxyZWFkeSBhIHNpZ25pZmljYW50IGRlZ3Jh ZGF0aW9uIGltcG9zZWQgb24gV2ViIOKAkyBMVEUgbGlua3MgaWYgb25seSBNVEkgY29kZWNzIGFy ZSB1c2VkLiAgVGhlIG9ubHkgc3lzdGVtcyB0byBhdm9pZCB0aGlzIGFyZSB0aG9zZSB3aGljaCBp bXBsZW1lbnQgT1BUSU9OQUwgYXVkaW8gY29kZWNzIHRvIGJlIHRyYW5zY29kZXItZnJlZSB3aXRo IExURS4gIFRoZSBzYW1lIGNhbiBhcHBseSBmb3IgdmlkZW8gY29kZWNzLg0KDQpUaGUgR1NNQSB3 aGl0ZXBhcGVyIHJlZmVycyB0bzoNCg0KMS4gICAgIFF1YW50aXRhdGl2ZSB2b2ljZS1vdmVyLUxU RSAoVm9MVEUpIGRlbGF5IGxpbWl0cyB3ZXJlIGFncmVlZC10byBieSAzR1BQIFNBNCBpbiBBdWd1 c3QgMjAxNC4gIFRvIHBhcmFwaHJhc2UsIHBlcmZvcm1hbmNlIG9iamVjdGl2ZXMgZm9yIG1heGlt dW0gVm9MVEUgZGV2aWNlIGRlbGF5cyBpbiBlcnJvciBhbmQgaml0dGVyIGZyZWUgY29uZGl0aW9u cyBhbmQgQU1SIHNwZWVjaCBjb2RlYyBvcGVyYXRpb24sIHRoZSBzdW0gb2YgdGhlIFVFIGRlbGF5 cyBpbiBzZW5kaW5nIGFuZCByZWNlaXZpbmcgZGlyZWN0aW9ucyAoVFMgKyBUUikgc2hvdWxkIGJl IOKJpCAxNTBtcy4gSWYgdGhpcyBwZXJmb3JtYW5jZSBvYmplY3RpdmUgY2Fubm90IGJlIG1ldCwg dGhlIHN1bSBvZiB0aGUgVUUgZGVsYXlzIGluIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBkaXJlY3Rp b25zIChUUyArIFRSKSBzaGFsbCBpbiBhbnkgY2FzZSBiZSDiiaQgMTkwbXMuDQoNCjIuICAgICBP UFVTIOKAkyBBTVIgdHJhbnNjb2RpbmcgYWRkcyBhbiBhZGRpdGlvbmFsIDIxMS41IG1zIGltcGxl bWVudGF0aW9uLWFnbm9zdGljIChUUyArIFRSKSBkZWxheSwgaW5jbHVkaW5nIDQwIG1zIGZvciBq aXR0ZXIgYnVmZmVyIGFuZCA0MCBtcyBmb3IgZGlzY29udGludW91cyByZWNlcHRpb24gKERSWCku DQoNCjMuICAgICBUbyBwdXQgdGhlc2UgbnVtYmVycyBpbiBwZXJzcGVjdGl2ZSwgaXQgaXMgaW4g Z2VuZXJhbCBkZXNpcmFibGUgdG8gbWluaW1pemUgVUUgZGVsYXlzIHRvIGVuc3VyZSBsb3cgZW5v dWdoIGVuZC10by1lbmQgZGVsYXlzIGFuZCBoZW5jZSBhIGdvb2QgY29udmVyc2F0aW9uYWwgZXhw ZXJpZW5jZS4gIEluY3JlYXNpbmcgZGVsYXkgY2F1c2VzIHBlb3BsZSB0byBkb3VibGUtdGFsayBt YWtpbmcgY29udmVyc2F0aW9ucyBpbmNyZWFzaW5nbHkgZnJ1c3RyYXRpbmcuICBHdWlkYW5jZSB0 byBzdGF5IGJlbG93IDQwMCBtcyBtYXhpbXVtIG9uZS13YXkgZGVsYXkgaXMgZm91bmQgaW4gSVRV LVQgUmVjb21tZW5kYXRpb24gRy4xMTQgYW5kIHRoZSBjb21wdXRhdGlvbmFsIEUtbW9kZWwgaXMg aW4gSVRVLVQgUmVjb21tZW5kYXRpb24gRy4xMDcuDQoNClRoaXMgaXMgYSBjb21wbGV4IHRvcGlj IHdpdGggbWFueSBuZXR3b3JrIGZhY3RvcnMgaW4gcGxheS4gIExURSBvcGVyYXRvcnMgaW4gM0dQ UCBzZWVrIFVFIGRlbGF5cyAoVFMgKyBUUikgYXJvdW5kIDE1MCBtcy4gIEFkZGluZyBPUFVTIOKA kyBBTVIgdHJhbnNjb2RpbmcgaW4gdGhlIG5ldHdvcmsgaW1wb3NlcyBhbiBhZGRpdGlvbmFsIDIx MS41IG1zIG9uIHRvcCBvZiB0aGF0LCBqdXN0IGZvciBhdWRpby4gIE9wdGlvbmFsbHkgdXNpbmcg QU1SIGluIFdlYlJUQywgdGhvc2UgMjExLjUgbXMgY2FuIGJlIGVsaW1pbmF0ZWQsIGRlbGl2ZXJp bmcgYSBzdXBlcmlvciBlbmQtdXNlciBleHBlcmllbmNlLg0KDQpDT05DTFVTSU9OOiAgcmVnYXJk bGVzcyBvZiBNVEkgY29kZWMgY2hvaWNlcyBpbiBXZWJSVEMsIHRvIHByb3ZpZGUgYSBnb29kIFdl YlJUQyDigJMgTFRFIGludGVyb3AgZXhwZXJpZW5jZSwgZW1lcmdpbmcgV2ViUlRDIHN5c3RlbXMg bXVzdCBhY2NvbW1vZGF0ZSBNVEkgY29kZWNzIGFscmVhZHkgZGVwbG95ZWQgaW4gdGhlIExURSBk b21haW4gYW5kIGluIG1vYmlsZSBvcGVyYXRpbmcgc3lzdGVtcywgbmFtZWx5IEFNUi9BTVItV0Ig YW5kIEguMjY0Lg0KDQpQT1NJVElPTjogIFRvIGJlIGNsZWFyLCBzZXZlcmFsIEludGVsIFNvQ3Mg bGF1bmNoZWQgYXQgTVdDIHRoaXMgeWVhciBmb3Igc21hcnRwaG9uZXMgYW5kIHRhYmxldHMgc3Vw cG9ydCBib3RoIFZQOCBhbmQgSC4yNjQgaGFyZHdhcmUgZW5jb2RlIGFuZCBkZWNvZGUg4oCTIHNv IEludGVsIGlzIGNvZGVjLW5ldXRyYWwgaW4gdGhpcyBNVEkgZGViYXRlLiAgQWRkaXRpb25hbGx5 LCBJbnRlbCBoYXMgaGlnaC1wZXJmb3JtYW5jZSBzb2x1dGlvbnMgZm9yIHRyYW5zY29kaW5nLiAg SG93ZXZlciwgd2Ugd2lzaCB0byBpbmZvcm0gdGhlIGluZHVzdHJ5LCB3aXRoIHF1YW50aXRhdGl2 ZSBkYXRhLCBhYm91dCBpbXBhY3QgdG8gZW5kLXVzZXIgZXhwZXJpZW5jZSBvZiBtYW5kYXRpbmcg c3VjaCB0cmFuc2NvZGluZyBzbyBJRVRGIGNhbiBtYWtlIGEgZGF0YS1kcml2ZW4gZGVjaXNpb24g b24gdmlkZW8gY29kZWNzIGFzIHdlbGwgYXMgcmVmbGVjdCBvbiB0aGUgaW1wYWN0IG9mIGFscmVh ZHkgaGF2aW5nIG1hbmRhdGVkIHRyYW5zY29kaW5nIG9uIHRoZSBhdWRpbyBzaWRlLg0KDQpDaHJp cyBDYXZpZ2lvbGkNCkludGVsIENvcnAsIFN5c3RlbSBBcmNoaXRlY3R1cmUgYW5kIFBsYW5uaW5n LCBWaWRlby9NdWx0aW1lZGlhLCBNb2JpbGUgYW5kIENvbW11bmljYXRpb25zIEdyb3VwIChNQ0cp DQorMSAoNDE1KSAyNTQtNDU0NSBtb2JpbGUNCisxICg0MDgpIDY1My04MzQ4IGRlc2sNCisxICg0 MDgpIDg4NC0yNDAwIGZheA0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4NCg0KRnJvbTog cnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJu YXJkIEFib2JhDQpTZW50OiBTdW5kYXksIE9jdG9iZXIgMTksIDIwMTQgMjoyOSBQTQ0KVG86IEhh cmFsZCBBbHZlc3RyYW5kDQpDYzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gUGxhbiBmb3IgTVRJIHZpZGVvIGNvZGVjPw0KDQpIYXJhbGQgc2FpZDoNCg0KIkJlcm5hcmQs DQoNCkkgdGhpbmsgdGhpcyBpcywgdG8gYSBsYXJnZSBkZWdyZWUsIGNvZGVjIGluZGVwZW5kZW50 Lg0KDQpXZSBoYXZlIGRlbW9uc3RyYXRlZCBpbnRlcm9wZXJhYmlsaXR5IG9uIFZQOCBiZXR3ZWVu IEZpcmVmb3ggYW5kIENocm9tZSwgYW5kIHVzYWdlIG9mIHZhcmlvdXMgbWVjaGFuaXNtcyBmb3Ig Y29uZ2VzdGlvbiBjb250cm9sIGFuZCByZXBhaXIgb2YgcGFja2V0IGxvc3MgYmVpbmcgYXBwbGll ZCBpbiBsaXZlIHNlcnZpY2VzLg0KU28gaXQgY2FuJ3QgYmUgYWxsIGJhZC4uLi4uIg0KDQpbQkFd ICBJIGFncmVlIHRoYXQgdGhlIGxhY2sgb2YgaW50ZXJvcGVyYWJpbGl0eSBpcyBsYXJnZWx5ICJj b2RlYyBpbmRlcGVuZGVudCI6ICAgdGhhdCBpcywgaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGRp ZmZlcmVudCBtZWNoYW5pc21zIGZvciBjb25nZXN0aW9uIGNvbnRyb2wsIHJlcGFpciwgZXRjLiB3 aWxsIGV4aGliaXQgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcywgcmVnYXJkbGVzcyBvZiB0aGUg Y29kZWMgY2hvc2VuLiAgIFRoZSByZWFsIHRlc3QgZm9yIFJUQ1dFQiB3aWxsIGJlIHRvIG1vdmUg YmV5b25kICJpbnRlcm9wZXJhYmlsaXR5IG9mIGltcGxlbWVudGF0aW9ucyBzaGFyaW5nIHNvdXJj ZSBjb2RlIiAgdG8gImludGVyb3BlcmFiaWxpdHkgb2YgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRp b25zLCBiYXNlZCBvbiBvcGVuIHN0YW5kYXJkcyIuDQoNCk9uIFN1biwgT2N0IDE5LCAyMDE0IGF0 IDE6MzggUE0sIEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86 aGFyYWxkQGFsdmVzdHJhbmQubm8+PiB3cm90ZToNCk9uIDEwLzE5LzIwMTQgMDU6NDMgUE0sIEJl cm5hcmQgQWJvYmEgd3JvdGU6DQoiQW5kIGl0cyBvbmUgb2YgdGhlIGlzc3VlcyBob2xkaW5nIHVw IHdpZGVyIGFkb3B0aW9uIG9mIHRoZSB0ZWNobm9sb2d5Ig0KDQpbQkFdIFNwZWNpZnlpbmcgYW4g TVRJIGVuY29kZXIvZGVjb2RlciBpcyBub3Qgc3VmZmljaWVudCBmb3IgaW50ZXJvcGVyYWJpbGl0 eS4gIEl0IGlzIGFsc28gbmVjZXNzYXJ5IHRvIHNwZWNpZnkgdGhlIHRyYW5zcG9ydCBpbiBlbm91 Z2ggZGV0YWlsIHRvIGFsbG93IGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucyB0aGF0IGludGVy b3BlcmF0ZSB3ZWxsIGVub3VnaCB0byBiZSB1c2FibGUgaW4gYSB3aWRlIHZhcmlldHkgb2Ygc2Nl bmFyaW9zLCBpbmNsdWRpbmcgd2lyZWxlc3MgbmV0d29ya3Mgd2hlcmUgbG9zcyBpcyBjb21tb25s eSBleHBlcmllbmNlZC4NCg0KQmVybmFyZCwNCg0KSSB0aGluayB0aGlzIGlzLCB0byBhIGxhcmdl IGRlZ3JlZSwgY29kZWMgaW5kZXBlbmRlbnQuDQoNCldlIGhhdmUgZGVtb25zdHJhdGVkIGludGVy b3BlcmFiaWxpdHkgb24gVlA4IGJldHdlZW4gRmlyZWZveCBhbmQgQ2hyb21lLCBhbmQgdXNhZ2Ug b2YgdmFyaW91cyBtZWNoYW5pc21zIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIHJlcGFpciBv ZiBwYWNrZXQgbG9zcyBiZWluZyBhcHBsaWVkIGluIGxpdmUgc2VydmljZXMuDQoNClNvIGl0IGNh bid0IGJlIGFsbCBiYWQuLi4uLg0KDQoNCg0KDQpXZSBtYWRlIHRoZSBtaXN0YWtlIG9mIGhhdmlu ZyBhbiBNVEkgZGlzY3Vzc2lvbiBwcmV2aW91c2x5IHdpdGggbm90IGVub3VnaCBkZXRhaWxzIG9u IHRoYXQgc3ViamVjdCwgcGFydGljdWxhcmx5IHdpdGggcmVzcGVjdCB0byBILjI2NC4gZHJhZnQt aWV0Zi1ydGN3ZWItdmlkZW8gc2VjdGlvbnMgNC4yIC0gNC40IHJlbWFpbiBza2V0Y2h5IGF0IGJl c3QuDQoNClNvIGlmIHdlIGFyZSB0byBoYXZlIHRoZSBkaXNjdXNzaW9uIGFnYWluLCBpdCBzaG91 bGQgb2NjdXIgaW4gdGhlIGNvbnRleHQgb2YgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbnMgYW5kIGlu dGVyb3BlcmFiaWxpdHkgcmVwb3J0cy4NCg0KDQoNCg0KDQpPbiBTdW4sIE9jdCAxOSwgMjAxNCBh dCA4OjE0IEFNLCBKb25hdGhhbiBSb3NlbmJlcmcgPGpkcm9zZW5AamRyb3Nlbi5uZXQ8bWFpbHRv Ompkcm9zZW5AamRyb3Nlbi5uZXQ+PiB3cm90ZToNCkknbSBpbiBmYXZvciBvZiB0YWtpbmcgYW5v dGhlciBydW4gYXQgdGhpcy4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHJlcGVhdGVkbHkgc2Fp ZCB0aGF0IGFuIE1USSBjb2RlYyBpcyBzb21ldGhpbmcgd2UgbmVlZCB0byBwcm9kdWNlLiBBbmQg aXRzIG9uZSBvZiB0aGUgaXNzdWVzIGhvbGRpbmcgdXAgd2lkZXIgYWRvcHRpb24gb2YgdGhlIHRl Y2hub2xvZ3kgKG5vdCB0aGUgb25seSBvbmUgZm9yIHN1cmUpLg0KDQpBbmQgdGhpbmdzIGhhdmUg Y2hhbmdlZCBzaW5jZSB0aGUgbGFzdCBtZWV0aW5nLCBhIHllYXIgYWdvIG5vdyAoTm92ZW1iZXIg aW4gVmFuY291dmVyKS4gQ2lzY28ncyBvcGVuMjY0IHBsdWdpbiBzaGlwcGVkIGFuZCBub3cganVz dCByZWNlbnRseSBpcyBpbnRlZ3JhdGVkIGludG8gRmlyZWZveC4gaU9TOCBzaGlwcGVkIHdpdGgg QVBJcyBmb3IgSDI2NC4gVGhlcmUgYXJlIG90aGVyIHRoaW5ncyB3b3J0aCBub3RpbmcuIFdpbGwg dGhpcyBjaGFuZ2UgdGhlIG1pbmRzIG9mIGV2ZXJ5b25lPyBTdXJlbHkgbm90LiBXaWxsIGl0IHN3 YXkgZW5vdWdoIGZvciB1cyB0byBhY2hpZXZlIHJvdWdoIGNvbnNlbnN1cz8gTWF5YmUuIElNSE8g LSB3b3J0aCBmaW5kaW5nIG91dC4NCg0KT24gU2F0LCBPY3QgMTgsIDIwMTQgYXQgNTowOCBQTSwg QWxleGFuZHJlIEdPVUFJTExBUkQgPGFnb3VhaWxsYXJkQGdtYWlsLmNvbTxtYWlsdG86YWdvdWFp bGxhcmRAZ21haWwuY29tPj4gd3JvdGU6DQorMSB0byBub3QgaGF2aW5nIE1USSBjb2RlYyBkaXNj dXNzaW9uIHVubGVzcyBzb21lIHByb2dyZXNzIGhhcyBiZWVuIG1hZGUgb24gVlA4IGF0IE1QRUcu IEFueSBuZXdzIG9uIHRoYXQ/IEknbSBzaGFyaW5nIGhhcmFsZCdzICBmZWVsaW5nIHRoYXQgdGhl cmUgd2FzIG5vIGNoYW5nZSBvbiB0aGUgbWVtYmVycyBwb3NpdGlvbi4NCg0KT24gRnJpLCBPY3Qg MTcsIDIwMTQgYXQgOToyMiBQTSwgSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5k Lm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubz4+IHdyb3RlOg0KT24gMTAvMTcvMjAxNCAx MjowMiBBTSwgQmVybmFyZCBBYm9iYSB3cm90ZToNCk9uZSB0aGluZyB3ZSBjb3VsZCBkbyBpbnN0 ZWFkIG9mIHdhc3RpbmcgdGltZSBvbiBNVEkgaXMgdG8gYWN0dWFsbHkgbWFrZSBwcm9ncmVzcyBv biBTZWN0aW9ucyA0LjIgLSA0LjQgb2YgZHJhZnQtSUVURi1SVENXRUItdmlkZW8sIHNvIHdlIGNv dWxkIGFjdHVhbGx5IGludGVyb3BlcmF0ZSByZWdhcmRsZXNzIG9mIHRoZSBjb2RlYy4NCg0KVGhl IGJpZyBhcmd1bWVudCBmb3IgYW4gTVRJIGlzIGFjdHVhbGx5IHRoZSBvbmUgc3RhdGVkIGluIC1v dmVydmlldzogSXQgZ3VhcmRzIGFnYWluc3QgaW50ZXJvcGVyYWJpbGl0eSBmYWlsdXJlLg0KDQpJ IHdvdWxkIGxpa2UgdG8gaGF2ZSBhbiBlY29zeXN0ZW0gd2hlcmUgb25lIGNhbiBmaWVsZCBhIGJv eCwgY29ubmVjdCBpdCB0byBldmVyeXRoaW5nIGVsc2UsIGFuZCBydW4gd2VsbCBmb3IgKnNvbWUq IGxldmVsIG9mICJ3ZWxsIiAtIGFuZCBJIHdvdWxkIHByZWZlciB0aGF0IGVjb3N5c3RlbSB0byBi ZSBvbmUgd2hlcmUgaXQncyBwb3NzaWJsZSB0byBmaWVsZCB0aGUgYm94IHdpdGhvdXQgbWFraW5n IHByaW9yIGFycmFuZ2VtZW50cyB3aXRoIGFueW9uZSBhYm91dCBsaWNlbnNlcy4NCg0KVGhpcyBh cmd1bWVudCBoYXNuJ3QgY2hhbmdlZCBvbmUgd2hpdCBzaW5jZSBsYXN0IHRpbWUgd2UgZGlzY3Vz c2VkIGl0LiBBbmQgSSBkb24ndCBzZWUgbXVjaCBtb3ZlbWVudCBvbiB0aGUgc3BlY2lmaWNzIG9m IHRoZSBwcm9wb3NhbHMgZWl0aGVyLg0KDQpXZSdsbCBoYXZlIHRvIGludGVyb3BlcmF0ZSB3ZWxs IHdpdGggdGhlIGNvZGVjcyB3ZSBmaWVsZC4gU28gdXNpbmcgc29tZSB0aW1lIHRvIGRpc2N1c3Mg ZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8gc2VlbXMgdG8gbWFrZSBzZW5zZS4gKEFuZCA0LjEgaXNu J3QgZmluaXNoZWQgZWl0aGVyLiBUaGVyZSdzIG9uZSBzZW50ZW5jZSB0aGF0IG5lZWRzIHRvIGJl IHJlbW92ZWQuKQ0KDQpJIHdvdWxkbid0IHNheSBJJ2QgYmUgaGFwcHkgdG8gbm90IGRpc2N1c3Mg dGhpcyBpbiBIb25vbHVsdS4gQnV0IEknZCBwcmVmZXIgdG8gcmUtZGlzY3VzcyBiYXNlZCBvbiB0 aGUga25vd2xlZGdlIHRoYXQgc29tZSBzaWduaWZpY2FudCBwbGF5ZXJzIGhhdmUgYWN0dWFsbHkg Y2hhbmdlZCB0aGVpciBtaW5kcy4NCg0KQXQgdGhlIG1vbWVudCwgSSBkb24ndCBzZWUgc2lnbnMg dGhhdCBhbnkgb2YgdGhlIHBvbGwgcmVzcG9uZGVudHMgaGF2ZSBzYWlkICJJIGhhdmUgY2hhbmdl ZCBteSBtaW5kIi4NCg0KSGFyYWxkDQoNCg0KDQoNCk9uIE9jdCAxNiwgMjAxNCwgYXQgMjoyOCBQ TSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpPbiAxNiBPY3RvYmVyIDIwMTQgMTQ6MTcsIE1h dHRoZXcgS2F1Zm1hbiA8bWF0dGhld0BtYXR0aGV3LmF0PG1haWx0bzptYXR0aGV3QG1hdHRoZXcu YXQ+PiB3cm90ZToNCkFuZCB0aGF0J3MgYmVjYXVzZSBzb21ldGhpbmcgc3Vic3RhbnRpdmUgaGFz IGNoYW5nZWQsIG9yIHNpbXBseSBiZWNhdXNlDQp3YXN0aW5nIHRoZSBXRyB0aW1lIG9uIHRoaXMg YWdhaW4gaXMgbW9yZSBlbnRlcnRhaW5pbmcgdGhhbiBhY3R1YWxseQ0KZmluaXNoaW5nIGEgc3Bl Y2lmaWNhdGlvbiB0aGF0IGNhbiBiZSBpbmRlcGVuZGVudGx5IGltcGxlbWVudGVkIGJ5IGFsbA0K YnJvd3NlciB2ZW5kb3JzPyAoQSBzcGVjaWZpY2F0aW9uIHRoYXQgd2UgYXJlIG5vd2hlcmUgbmVh ciBoYXZpbmcsIGFzIGZhciBhcw0KSSBjYW4gdGVsbCkNClBlcnNvbmFsbHksIEkndmUgZm91bmQg dGhlIHJlcHJpZXZlIGZyb20gdGhpcyBmaWdodCByZWZyZXNoaW5nLiAgQW5kDQppdCB3b3VsZCBh cHBlYXIgdGhhdCB3ZSd2ZSBtYWRlIHNvbWUgcmVhbCBwcm9ncmVzcyBhcyBhIHJlc3VsdC4gIEkn ZA0Kc3VnZ2VzdCB0aGF0IGlmIHdlIGRvbid0IGhhdmUgbmV3IGluZm9ybWF0aW9uLCB3ZSBjb250 aW51ZSB0byBzcGVuZA0Kb3VyIHRpbWUgcHJvZHVjdGl2ZWx5LiAgSWYgd2UgY2FuJ3QgZmluZCB0 b3BpY3MgdG8gb2NjdXB5IG91ciBtZWV0aW5nDQphZ2VuZGEgdGltZSwgdGhlbiBtYXliZSB3ZSBj YW4gZnJlZSBhbiBhZ2VuZGEgc2xvdC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxt YWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIg bWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQotLQ0KQWxl eC4gR291YWlsbGFyZCwgUGhELCBQaEQsIE1CQQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpDVE8gLSBUZW1hc3lzIENvbW11bmljYXRpb25zLCBTJ3BvcmUgLyBNb3VudGFpbiBWaWV3DQpQ cmVzaWRlbnQgLSBDb1NNbyBTb2Z0d2FyZSwgQ2FtYnJpZGdlLCBNQQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpzZy5saW5rZWRpbi5jb20vYWdvdWFpbGxhcmQ8aHR0cDovL3NnLmxpbmtl ZGluLmNvbS9hZ291YWlsbGFyZD4NCsK3DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViDQoNCg0KDQotLQ0KSm9uYXRoYW4gUm9zZW5iZXJnLCBQaC5ELg0KamRyb3Nl bkBqZHJvc2VuLm5ldDxtYWlsdG86amRyb3NlbkBqZHJvc2VuLm5ldD4NCmh0dHA6Ly93d3cuamRy b3Nlbi5uZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCnJ0 Y3dlYiBtYWlsaW5nIGxpc3QNCg0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5v cmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0K LS0NCg0KU3VydmVpbGxhbmNlIGlzIHBlcnZhc2l2ZS4gR28gRGFyay4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QN CnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_E36D1A4AE0B6AA4091F1728D584A6AD2400622F1ORSMSX158amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTppbmhl cml0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5v c2UtMToyIDExIDYgOSA0IDUgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkFu ZGFsdXM7DQoJcGFub3NlLTE6MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5ob2VuemINCgl7bXNv LXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDg5MDk3NjI0Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTgyNjM0MTczMjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6NjgwODYxODA2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTM0OTQ3ODcyIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhhcmFsZCBz YWlkOiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ 4oCcV2UgbWFkZSB0aGUgbWlzdGFrZSBvZiBoYXZpbmcgYW4gTVRJIGRpc2N1c3Npb24gcHJldmlv dXNseSB3aXRoIG5vdCBlbm91Z2ggZGV0YWlscyBvbiB0aGF0IHN1YmplY3TigKbigJ08c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBkaWRu4oCZdCBoYXZl IHF1YW50aXRhdGl2ZSBkYXRhIGVhcmxpZXIgZm9yIGEgZGF0YS1kcml2ZW4gZGVjaXNpb24uJm5i c3A7IEZ1dHVyZSBXZWIg4oCTIExURSBpbnRlcm9wIGlzIGltcG9ydGFudC4mbmJzcDsgQSBncm91 cCBvZiB1cyBpbiBHU01BIGhhdmUgYmVlbiBsb29raW5nIGF0IFdlYlJUQw0KIGludGVyb3Agd2l0 aCBMVEUgKHdoZXJlIDNHUFAgLyBHU01BIGRlZmluZWQgSU1TLWJhc2VkIHZvaWNlL3ZpZGVvL21l c3NhZ2luZyksIHNwZWNpZmljYWxseSBsb29raW5nIGF0IHVzZXIgZXhwZXJpZW5jZSBpbXBhY3Qg b2YgbGF0ZW5jeSBpbnRyb2R1Y2VkIGJ5IGFkZGVkIGluLW5ldHdvcmsgdHJhbnNjb2RpbmcuJm5i c3A7IEdTTUEgaGFzIGFwcHJvdmVkIHRoZSB3aGl0ZXBhcGVyIGFuZCBpdCBpcyBiZWluZyBwcmVw YXJlZCBmb3IgcHVibGljIGRpc3RyaWJ1dGlvbi4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZWJSVEMg4oCTIExU RSB0cmFuc2NvZGluZyBpcyBub3cgTUFOREFUT1JZIGJlY2F1c2Ugb2Yg4oCcV2ViUlRDIEF1ZGlv IENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVpcmVtZW50c+KAnS4NCjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTA1Ij5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0wNTwvYT4sIHdoZXJlIE1U SSBhdWRpbyBjb2RlY3MgaW4gV2ViUlRDIGFuZCBpbiBMVEUgYXJlIGRpc3NpbWlsYXIuJm5ic3A7 IFRodXMsIFJFR0FSRExFU1Mgb2YgdGhlIHZpZGVvIGNvZGVjcywgdGhlcmUgaXMgYWxyZWFkeSBh IHNpZ25pZmljYW50IGRlZ3JhZGF0aW9uDQogaW1wb3NlZCBvbiBXZWIg4oCTIExURSBsaW5rcyBp ZiBvbmx5IE1USSBjb2RlY3MgYXJlIHVzZWQuJm5ic3A7IFRoZSBvbmx5IHN5c3RlbXMgdG8gYXZv aWQgdGhpcyBhcmUgdGhvc2Ugd2hpY2ggaW1wbGVtZW50IE9QVElPTkFMIGF1ZGlvIGNvZGVjcyB0 byBiZSB0cmFuc2NvZGVyLWZyZWUgd2l0aCBMVEUuJm5ic3A7IFRoZSBzYW1lIGNhbiBhcHBseSBm b3IgdmlkZW8gY29kZWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgR1NNQSB3aGl0ZXBhcGVyIHJlZmVycyB0bzo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5RdWFudGl0YXRpdmUgdm9pY2Utb3Zlci1MVEUgKFZvTFRFKSBkZWxheSBsaW1pdHMgd2VyZSBh Z3JlZWQtdG8gYnkgM0dQUCBTQTQgaW4gQXVndXN0IDIwMTQuJm5ic3A7IFRvIHBhcmFwaHJhc2Us IHBlcmZvcm1hbmNlIG9iamVjdGl2ZXMgZm9yIG1heGltdW0gVm9MVEUNCiBkZXZpY2UgZGVsYXlz IGluIGVycm9yIGFuZCBqaXR0ZXIgZnJlZSBjb25kaXRpb25zIGFuZCBBTVIgc3BlZWNoIGNvZGVj IG9wZXJhdGlvbiwgdGhlIHN1bSBvZiB0aGUgVUUgZGVsYXlzIGluIHNlbmRpbmcgYW5kIHJlY2Vp dmluZyBkaXJlY3Rpb25zIChUPHN1Yj5TPC9zdWI+ICYjNDM7IFQ8c3ViPlI8L3N1Yj4pIHNob3Vs ZCBiZSDiiaQgMTUwbXMuIElmIHRoaXMgcGVyZm9ybWFuY2Ugb2JqZWN0aXZlIGNhbm5vdCBiZSBt ZXQsIHRoZSBzdW0gb2YgdGhlIFVFDQogZGVsYXlzIGluIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBk aXJlY3Rpb25zIChUPHN1Yj5TPC9zdWI+ICYjNDM7IFQ8c3ViPlI8L3N1Yj4pIHNoYWxsIGluIGFu eSBjYXNlIGJlIOKJpCAxOTBtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZl bDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PUFVTIOKAkyBBTVIgdHJhbnNjb2RpbmcgYWRkcyBh biBhZGRpdGlvbmFsIDIxMS41IG1zIGltcGxlbWVudGF0aW9uLWFnbm9zdGljIChUPHN1Yj5TPC9z dWI+ICYjNDM7IFQ8c3ViPlI8L3N1Yj4pIGRlbGF5LCBpbmNsdWRpbmcgNDAgbXMgZm9yIGppdHRl ciBidWZmZXINCiBhbmQgNDAgbXMgZm9yIGRpc2NvbnRpbnVvdXMgcmVjZXB0aW9uIChEUlgpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRvIHB1dCB0aGVzZSBudW1iZXJzIGluIHBlcnNwZWN0aXZlLCBpdCBpcyBpbiBnZW5lcmFs IGRlc2lyYWJsZSB0byBtaW5pbWl6ZSBVRSBkZWxheXMgdG8gZW5zdXJlIGxvdyBlbm91Z2ggZW5k LXRvLWVuZCBkZWxheXMgYW5kIGhlbmNlIGEgZ29vZCBjb252ZXJzYXRpb25hbA0KIGV4cGVyaWVu Y2UuJm5ic3A7IEluY3JlYXNpbmcgZGVsYXkgY2F1c2VzIHBlb3BsZSB0byBkb3VibGUtdGFsayBt YWtpbmcgY29udmVyc2F0aW9ucyBpbmNyZWFzaW5nbHkgZnJ1c3RyYXRpbmcuJm5ic3A7IEd1aWRh bmNlIHRvIHN0YXkgYmVsb3cgNDAwIG1zIG1heGltdW0gb25lLXdheSBkZWxheSBpcyBmb3VuZCBp biBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjExNCBhbmQgdGhlIGNvbXB1dGF0aW9uYWwgRS1tb2Rl bCBpcyBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjEwNy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhIGNvbXBs ZXggdG9waWMgd2l0aCBtYW55IG5ldHdvcmsgZmFjdG9ycyBpbiBwbGF5LiZuYnNwOyBMVEUgb3Bl cmF0b3JzIGluIDNHUFAgc2VlayBVRSBkZWxheXMgKFQ8c3ViPlM8L3N1Yj4gJiM0MzsgVDxzdWI+ Ujwvc3ViPikgYXJvdW5kIDE1MCBtcy4mbmJzcDsgQWRkaW5nIE9QVVMg4oCTDQogQU1SIHRyYW5z Y29kaW5nIGluIHRoZSBuZXR3b3JrIGltcG9zZXMgYW4gYWRkaXRpb25hbCAyMTEuNSBtcyBvbiB0 b3Agb2YgdGhhdCwganVzdCBmb3IgYXVkaW8uJm5ic3A7IE9wdGlvbmFsbHkgdXNpbmcgQU1SIGlu IFdlYlJUQywgdGhvc2UgMjExLjUgbXMgY2FuIGJlIGVsaW1pbmF0ZWQsIGRlbGl2ZXJpbmcgYSBz dXBlcmlvciBlbmQtdXNlciBleHBlcmllbmNlLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNPTkNMVVNJT046ICZu YnNwO3JlZ2FyZGxlc3Mgb2YgTVRJIGNvZGVjIGNob2ljZXMgaW4gV2ViUlRDLCB0byBwcm92aWRl IGEgZ29vZCBXZWJSVEMg4oCTIExURSBpbnRlcm9wIGV4cGVyaWVuY2UsIGVtZXJnaW5nIFdlYlJU QyBzeXN0ZW1zIG11c3QgYWNjb21tb2RhdGUgTVRJIGNvZGVjcw0KIGFscmVhZHkgZGVwbG95ZWQg aW4gdGhlIExURSBkb21haW4gYW5kIGluIG1vYmlsZSBvcGVyYXRpbmcgc3lzdGVtcywgbmFtZWx5 IEFNUi9BTVItV0IgYW5kIEguMjY0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QT1NJVElPTjombmJzcDsgVG8gYmUgY2xlYXIs IHNldmVyYWwgSW50ZWwgU29DcyBsYXVuY2hlZCBhdCBNV0MgdGhpcyB5ZWFyIGZvciBzbWFydHBo b25lcyBhbmQgdGFibGV0cyBzdXBwb3J0IGJvdGggVlA4IGFuZCBILjI2NCBoYXJkd2FyZSBlbmNv ZGUgYW5kIGRlY29kZSDigJMgc28gSW50ZWwNCiBpcyBjb2RlYy1uZXV0cmFsIGluIHRoaXMgTVRJ IGRlYmF0ZS4mbmJzcDsgQWRkaXRpb25hbGx5LCBJbnRlbCBoYXMgaGlnaC1wZXJmb3JtYW5jZSBz b2x1dGlvbnMgZm9yIHRyYW5zY29kaW5nLiZuYnNwOyBIb3dldmVyLCB3ZSB3aXNoIHRvIGluZm9y bSB0aGUgaW5kdXN0cnksIHdpdGggcXVhbnRpdGF0aXZlIGRhdGEsIGFib3V0IGltcGFjdCB0byBl bmQtdXNlciBleHBlcmllbmNlIG9mIG1hbmRhdGluZyBzdWNoIHRyYW5zY29kaW5nIHNvIElFVEYg Y2FuIG1ha2UgYQ0KIGRhdGEtZHJpdmVuIGRlY2lzaW9uIG9uIHZpZGVvIGNvZGVjcyBhcyB3ZWxs IGFzIHJlZmxlY3Qgb24gdGhlIGltcGFjdCBvZiBhbHJlYWR5IGhhdmluZyBtYW5kYXRlZCB0cmFu c2NvZGluZyBvbiB0aGUgYXVkaW8gc2lkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjojMUY0OTdE Ij5DaHJpcyBDYXZpZ2lvbGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbnRlbCBDb3Jw LA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPlN5c3Rl bSBBcmNoaXRlY3R1cmUgYW5kIFBsYW5uaW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiwgVmlkZW8vTXVsdGltZWRpYSwgTW9iaWxlIGFuZCBDb21tdW5p Y2F0aW9ucyBHcm91cCAoTUNHKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOzEgKDQxNSkgMjU0 LTQ1NDUgbW9iaWxlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYjNDM7MSAoNDA4KSA2NTMtODM0OCBk ZXNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsxICg0MDgpIDg4NC0yNDAwIGZh eDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpncmF5Ij5UaGlzIGUtbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLiZuYnNwOyBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4NCiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVybmFyZCBBYm9i YTxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE9jdG9iZXIgMTksIDIwMTQgMjoyOSBQTTxicj4N CjxiPlRvOjwvYj4gSGFyYWxkIEFsdmVzdHJhbmQ8YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUGxhbiBmb3IgTVRJIHZpZGVv IGNvZGVjPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhcmFsZCBzYWlk OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1 b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmVybmFyZCw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KSSB0aGluayB0aGlzIGlzLCB0 byBhIGxhcmdlIGRlZ3JlZSwgY29kZWMgaW5kZXBlbmRlbnQuPGJyPg0KPGJyPg0KV2UgaGF2ZSBk ZW1vbnN0cmF0ZWQgaW50ZXJvcGVyYWJpbGl0eSBvbiBWUDggYmV0d2VlbiBGaXJlZm94IGFuZCBD aHJvbWUsIGFuZCB1c2FnZSBvZiB2YXJpb3VzIG1lY2hhbmlzbXMgZm9yIGNvbmdlc3Rpb24gY29u dHJvbCBhbmQgcmVwYWlyIG9mIHBhY2tldCBsb3NzIGJlaW5nIGFwcGxpZWQgaW4gbGl2ZSBzZXJ2 aWNlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U28gaXQgY2FuJ3QgYmUgYWxsIGJhZC4uLi4uPC9z cGFuPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5bQkFdICZuYnNwO0kgYWdyZWUgdGhhdCB0aGUgbGFjayBvZiBpbnRlcm9wZXJhYmls aXR5IGlzIGxhcmdlbHkgJnF1b3Q7Y29kZWMgaW5kZXBlbmRlbnQmcXVvdDs6ICZuYnNwOyB0aGF0 IGlzLCBpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZGlmZmVyZW50IG1lY2hhbmlzbXMgZm9yIGNv bmdlc3Rpb24gY29udHJvbCwgcmVwYWlyLCBldGMuIHdpbGwgZXhoaWJpdCBpbnRlcm9wZXJhYmls aXR5IHByb2JsZW1zLCByZWdhcmRsZXNzIG9mIHRoZSBjb2RlYw0KIGNob3Nlbi4gJm5ic3A7IFRo ZSByZWFsIHRlc3QgZm9yIFJUQ1dFQiB3aWxsIGJlIHRvIG1vdmUgYmV5b25kICZxdW90O2ludGVy b3BlcmFiaWxpdHkgb2YgaW1wbGVtZW50YXRpb25zIHNoYXJpbmcgc291cmNlIGNvZGUmcXVvdDsg Jm5ic3A7dG8gJnF1b3Q7aW50ZXJvcGVyYWJpbGl0eSBvZiBpbmRlcGVuZGVudCBpbXBsZW1lbnRh dGlvbnMsIGJhc2VkIG9uIG9wZW4gc3RhbmRhcmRzJnF1b3Q7LiAmbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBP Y3QgMTksIDIwMTQgYXQgMTozOCBQTSwgSGFyYWxkIEFsdmVzdHJhbmQgJmx0OzxhIGhyZWY9Im1h aWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyIgdGFyZ2V0PSJfYmxhbmsiPmhhcmFsZEBhbHZlc3Ry YW5kLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDEwLzE5LzIwMTQgMDU6NDMgUE0sIEJlcm5hcmQgQWJvYmEgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZxdW90O0FuZCBpdHMgb25lIG9mIHRoZSBpc3N1ZXMgaG9sZGluZyB1cCB3aWRlciBhZG9wdGlv biBvZiB0aGUgdGVjaG5vbG9neSZxdW90Ow0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bQkFdIFNwZWNpZnlpbmcgYW4gTVRJIGVuY29kZXIvZGVjb2RlciBp cyBub3Qgc3VmZmljaWVudCBmb3IgaW50ZXJvcGVyYWJpbGl0eS4mbmJzcDsgSXQgaXMgYWxzbyBu ZWNlc3NhcnkgdG8gc3BlY2lmeSB0aGUgdHJhbnNwb3J0IGluIGVub3VnaCBkZXRhaWwgdG8gYWxs b3cgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIHRoYXQgaW50ZXJvcGVyYXRlIHdlbGwgZW5v dWdoIHRvIGJlIHVzYWJsZSBpbiBhIHdpZGUgdmFyaWV0eQ0KIG9mIHNjZW5hcmlvcywgaW5jbHVk aW5nIHdpcmVsZXNzIG5ldHdvcmtzIHdoZXJlIGxvc3MgaXMgY29tbW9ubHkgZXhwZXJpZW5jZWQu Jm5ic3A7IDxvOnA+DQo8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQmVybmFyZCw8YnI+DQo8YnI+DQpJIHRoaW5rIHRo aXMgaXMsIHRvIGEgbGFyZ2UgZGVncmVlLCBjb2RlYyBpbmRlcGVuZGVudC48YnI+DQo8YnI+DQpX ZSBoYXZlIGRlbW9uc3RyYXRlZCBpbnRlcm9wZXJhYmlsaXR5IG9uIFZQOCBiZXR3ZWVuIEZpcmVm b3ggYW5kIENocm9tZSwgYW5kIHVzYWdlIG9mIHZhcmlvdXMgbWVjaGFuaXNtcyBmb3IgY29uZ2Vz dGlvbiBjb250cm9sIGFuZCByZXBhaXIgb2YgcGFja2V0IGxvc3MgYmVpbmcgYXBwbGllZCBpbiBs aXZlIHNlcnZpY2VzLjxicj4NCjxicj4NClNvIGl0IGNhbid0IGJlIGFsbCBiYWQuLi4uLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XZSBtYWRlIHRoZSBtaXN0YWtlIG9mIGhhdmluZyBhbiBNVEkgZGlzY3Vzc2lvbiBwcmV2 aW91c2x5IHdpdGggbm90IGVub3VnaCBkZXRhaWxzIG9uIHRoYXQgc3ViamVjdCwgcGFydGljdWxh cmx5IHdpdGggcmVzcGVjdCB0byBILjI2NC4gZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8gc2VjdGlv bnMgNC4yIC0gNC40IHJlbWFpbiBza2V0Y2h5IGF0IGJlc3QuICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpZiB3ZSBhcmUgdG8g aGF2ZSB0aGUgZGlzY3Vzc2lvbiBhZ2FpbiwgaXQgc2hvdWxkIG9jY3VyIGluIHRoZSBjb250ZXh0 IG9mIGRldGFpbGVkIHNwZWNpZmljYXRpb25zIGFuZCBpbnRlcm9wZXJhYmlsaXR5IHJlcG9ydHMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gU3VuLCBPY3QgMTksIDIwMTQgYXQgODoxNCBBTSwgSm9uYXRoYW4gUm9zZW5iZXJn ICZsdDs8YSBocmVmPSJtYWlsdG86amRyb3NlbkBqZHJvc2VuLm5ldCIgdGFyZ2V0PSJfYmxhbmsi Pmpkcm9zZW5AamRyb3Nlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gaW4gZmF2b3Igb2YgdGFraW5nIGFub3RoZXIgcnVu IGF0IHRoaXMuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHJlcGVhdGVkbHkgc2FpZCB0aGF0IGFuIE1USSBjb2RlYyBp cyBzb21ldGhpbmcgd2UgbmVlZCB0byBwcm9kdWNlLiBBbmQgaXRzIG9uZSBvZiB0aGUgaXNzdWVz IGhvbGRpbmcgdXAgd2lkZXIgYWRvcHRpb24gb2YgdGhlIHRlY2hub2xvZ3kgKG5vdCB0aGUgb25s eSBvbmUgZm9yIHN1cmUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbmQgdGhpbmdzIGhhdmUgY2hhbmdlZCBzaW5jZSB0aGUgbGFzdCBtZWV0 aW5nLCBhIHllYXIgYWdvIG5vdyAoTm92ZW1iZXIgaW4gVmFuY291dmVyKS4gQ2lzY28ncyBvcGVu MjY0IHBsdWdpbiBzaGlwcGVkIGFuZCBub3cganVzdCByZWNlbnRseSBpcyBpbnRlZ3JhdGVkIGlu dG8gRmlyZWZveC4gaU9TOCBzaGlwcGVkIHdpdGggQVBJcyBmb3IgSDI2NC4gVGhlcmUgYXJlIG90 aGVyIHRoaW5ncyB3b3J0aCBub3RpbmcuDQogV2lsbCB0aGlzIGNoYW5nZSB0aGUgbWluZHMgb2Yg ZXZlcnlvbmU/IFN1cmVseSBub3QuIFdpbGwgaXQgc3dheSBlbm91Z2ggZm9yIHVzIHRvIGFjaGll dmUgcm91Z2ggY29uc2Vuc3VzPyBNYXliZS4gSU1ITyAtIHdvcnRoIGZpbmRpbmcgb3V0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFNhdCwgT2N0IDE4LCAyMDE0IGF0IDU6MDggUE0sIEFsZXhhbmRyZSBHT1VBSUxM QVJEICZsdDs8YSBocmVmPSJtYWlsdG86YWdvdWFpbGxhcmRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+YWdvdWFpbGxhcmRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIHRvIG5vdCBoYXZpbmcgTVRJIGNv ZGVjIGRpc2N1c3Npb24gdW5sZXNzIHNvbWUgcHJvZ3Jlc3MgaGFzIGJlZW4gbWFkZSBvbiBWUDgg YXQgTVBFRy4mbmJzcDtBbnkgbmV3cyBvbiB0aGF0PyBJJ20gc2hhcmluZyBoYXJhbGQncyAmbmJz cDtmZWVsaW5nIHRoYXQgdGhlcmUgd2FzIG5vIGNoYW5nZSBvbiB0aGUgbWVtYmVycyBwb3NpdGlv bi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gRnJpLCBPY3QgMTcsIDIwMTQgYXQgOToyMiBQTSwgSGFyYWxkIEFsdmVz dHJhbmQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyIgdGFyZ2V0PSJf YmxhbmsiPmhhcmFsZEBhbHZlc3RyYW5kLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMC8xNy8yMDE0IDEyOjAyIEFNLCBCZXJuYXJkIEFi b2JhIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIHRoaW5n IHdlIGNvdWxkIGRvIGluc3RlYWQgb2Ygd2FzdGluZyB0aW1lIG9uIE1USSBpcyB0byBhY3R1YWxs eSBtYWtlIHByb2dyZXNzIG9uIFNlY3Rpb25zIDQuMiAtIDQuNCBvZiBkcmFmdC1JRVRGLVJUQ1dF Qi12aWRlbywgc28gd2UgY291bGQgYWN0dWFsbHkgaW50ZXJvcGVyYXRlIHJlZ2FyZGxlc3Mgb2Yg dGhlIGNvZGVjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhl IGJpZyBhcmd1bWVudCBmb3IgYW4gTVRJIGlzIGFjdHVhbGx5IHRoZSBvbmUgc3RhdGVkIGluIC1v dmVydmlldzogSXQgZ3VhcmRzIGFnYWluc3QgaW50ZXJvcGVyYWJpbGl0eSBmYWlsdXJlLjxicj4N Cjxicj4NCkkgd291bGQgbGlrZSB0byBoYXZlIGFuIGVjb3N5c3RlbSB3aGVyZSBvbmUgY2FuIGZp ZWxkIGEgYm94LCBjb25uZWN0IGl0IHRvIGV2ZXJ5dGhpbmcgZWxzZSwgYW5kIHJ1biB3ZWxsIGZv ciAqc29tZSogbGV2ZWwgb2YgJnF1b3Q7d2VsbCZxdW90OyAtIGFuZCBJIHdvdWxkIHByZWZlciB0 aGF0IGVjb3N5c3RlbSB0byBiZSBvbmUgd2hlcmUgaXQncyBwb3NzaWJsZSB0byBmaWVsZCB0aGUg Ym94IHdpdGhvdXQgbWFraW5nIHByaW9yIGFycmFuZ2VtZW50cyB3aXRoIGFueW9uZQ0KIGFib3V0 IGxpY2Vuc2VzLjxicj4NCjxicj4NClRoaXMgYXJndW1lbnQgaGFzbid0IGNoYW5nZWQgb25lIHdo aXQgc2luY2UgbGFzdCB0aW1lIHdlIGRpc2N1c3NlZCBpdC4gQW5kIEkgZG9uJ3Qgc2VlIG11Y2gg bW92ZW1lbnQgb24gdGhlIHNwZWNpZmljcyBvZiB0aGUgcHJvcG9zYWxzIGVpdGhlci48YnI+DQo8 YnI+DQpXZSdsbCBoYXZlIHRvIGludGVyb3BlcmF0ZSB3ZWxsIHdpdGggdGhlIGNvZGVjcyB3ZSBm aWVsZC4gU28gdXNpbmcgc29tZSB0aW1lIHRvIGRpc2N1c3MgZHJhZnQtaWV0Zi1ydGN3ZWItdmlk ZW8gc2VlbXMgdG8gbWFrZSBzZW5zZS4gKEFuZCA0LjEgaXNuJ3QgZmluaXNoZWQgZWl0aGVyLiBU aGVyZSdzIG9uZSBzZW50ZW5jZSB0aGF0IG5lZWRzIHRvIGJlIHJlbW92ZWQuKTxicj4NCjxicj4N Ckkgd291bGRuJ3Qgc2F5IEknZCBiZSBoYXBweSB0byBub3QgZGlzY3VzcyB0aGlzIGluIEhvbm9s dWx1LiBCdXQgSSdkIHByZWZlciB0byByZS1kaXNjdXNzIGJhc2VkIG9uIHRoZSBrbm93bGVkZ2Ug dGhhdCBzb21lIHNpZ25pZmljYW50IHBsYXllcnMgaGF2ZSBhY3R1YWxseSBjaGFuZ2VkIHRoZWly IG1pbmRzLjxicj4NCjxicj4NCkF0IHRoZSBtb21lbnQsIEkgZG9uJ3Qgc2VlIHNpZ25zIHRoYXQg YW55IG9mIHRoZSBwb2xsIHJlc3BvbmRlbnRzIGhhdmUgc2FpZCAmcXVvdDtJIGhhdmUgY2hhbmdl ZCBteSBtaW5kJnF1b3Q7LjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQpI YXJhbGQ8L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gT2N0IDE2LCAyMDE0LCBhdCAyOjI4IFBNLCBNYXJ0 aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTYgT2N0b2JlciAyMDE0IDE0 OjE3LCBNYXR0aGV3IEthdWZtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYXR0aGV3QG1hdHRoZXcu YXQiIHRhcmdldD0iX2JsYW5rIj5tYXR0aGV3QG1hdHRoZXcuYXQ8L2E+Jmd0OyB3cm90ZTo8YnI+ DQpBbmQgdGhhdCdzIGJlY2F1c2Ugc29tZXRoaW5nIHN1YnN0YW50aXZlIGhhcyBjaGFuZ2VkLCBv ciBzaW1wbHkgYmVjYXVzZTxicj4NCndhc3RpbmcgdGhlIFdHIHRpbWUgb24gdGhpcyBhZ2FpbiBp cyBtb3JlIGVudGVydGFpbmluZyB0aGFuIGFjdHVhbGx5PGJyPg0KZmluaXNoaW5nIGEgc3BlY2lm aWNhdGlvbiB0aGF0IGNhbiBiZSBpbmRlcGVuZGVudGx5IGltcGxlbWVudGVkIGJ5IGFsbDxicj4N CmJyb3dzZXIgdmVuZG9ycz8gKEEgc3BlY2lmaWNhdGlvbiB0aGF0IHdlIGFyZSBub3doZXJlIG5l YXIgaGF2aW5nLCBhcyBmYXIgYXM8YnI+DQpJIGNhbiB0ZWxsKTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UGVyc29uYWxseSwgSSd2ZSBmb3VuZCB0aGUgcmVwcmlldmUgZnJv bSB0aGlzIGZpZ2h0IHJlZnJlc2hpbmcuJm5ic3A7IEFuZDxicj4NCml0IHdvdWxkIGFwcGVhciB0 aGF0IHdlJ3ZlIG1hZGUgc29tZSByZWFsIHByb2dyZXNzIGFzIGEgcmVzdWx0LiZuYnNwOyBJJ2Q8 YnI+DQpzdWdnZXN0IHRoYXQgaWYgd2UgZG9uJ3QgaGF2ZSBuZXcgaW5mb3JtYXRpb24sIHdlIGNv bnRpbnVlIHRvIHNwZW5kPGJyPg0Kb3VyIHRpbWUgcHJvZHVjdGl2ZWx5LiZuYnNwOyBJZiB3ZSBj YW4ndCBmaW5kIHRvcGljcyB0byBvY2N1cHkgb3VyIG1lZXRpbmc8YnI+DQphZ2VuZGEgdGltZSwg dGhlbiBtYXliZSB3ZSBjYW4gZnJlZSBhbiBhZ2VuZGEgc2xvdC48YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRj d2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi PkFsZXguIEdvdWFpbGxhcmQsIFBoRCwgUGhELCBNQkEgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij5DVE8gLSBUZW1hc3lzIENvbW11bmljYXRpb25zLCBTJ3BvcmUgLyBNb3VudGFpbiBWaWV3PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlByZXNpZGVudCAtIENvU01vIFNvZnR3YXJlLCBD YW1icmlkZ2UsIE1BPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YSBocmVmPSJodHRw Oi8vc2cubGlua2VkaW4uY29tL2Fnb3VhaWxsYXJkIiB0YXJnZXQ9Il9ibGFuayI+c2cubGlua2Vk aW4uY29tL2Fnb3VhaWxsYXJkPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRl bnQ6LS4yNWluO2xpbmUtaGVpZ2h0OjE0LjRwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTt2ZXJ0 aWNhbC1hbGlnbjpiYXNlbGluZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzMzMzMzMyI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6aW5oZXJpdDtjb2xvcjojMzMzMzMzIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb25hdGhhbiBSb3NlbmJlcmcs IFBoLkQuPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmpkcm9zZW5AamRyb3Nlbi5uZXQiIHRhcmdldD0i X2JsYW5rIj5qZHJvc2VuQGpkcm9zZW4ubmV0PC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cu amRyb3Nlbi5uZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lmpkcm9zZW4ubmV0PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5ydGN3ZWIgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBp ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+U3VydmVpbGxhbmNlIGlzIHBlcnZhc2l2ZS4gR28gRGFyay48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E36D1A4AE0B6AA4091F1728D584A6AD2400622F1ORSMSX158amrcor_-- From nobody Sun Oct 19 18:36:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F391A1A85 for ; Sun, 19 Oct 2014 18:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emxi5STSQnLi for ; Sun, 19 Oct 2014 18:36:14 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842871A1A8A for ; Sun, 19 Oct 2014 18:35:56 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so4255958wgh.21 for ; Sun, 19 Oct 2014 18:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2x0IuK2BsVwqM4FLvTANgPrSSLnHBhmtEfN45IW+9Qs=; b=DMaXTFAi3fdNkvy3TXh2iLLu93fpKq0x9aAoiO19LWb2TUFp9k8vMsC6lzx0qLQd4u 1rQqffT4rAKQjiTobLPKCSQcWQP0Mcm9tsQwRDbJPlhAPbikAePYrs8GVpX/g16BZn4F 5CauBU5pJtKZq/k4WjVKwYmIbcgBkC0fcrFC6/z0KRvQP7dCo1W1g7RgU+xJ0we/4c9G WfX42fcRb/2KE5dAoJCpu4MAj/p7eXwivIpKF72uv7SGhxbqjcy5X6yiLVp2IbYcE/Di 22vHU0Fnm4IinsrIn/Z/RC5f3/u/bcRfp28thDNQcjycjSIesQBz1WLPTi+0fwHaOw5c XjQg== MIME-Version: 1.0 X-Received: by 10.194.81.6 with SMTP id v6mr28381778wjx.39.1413768955178; Sun, 19 Oct 2014 18:35:55 -0700 (PDT) Received: by 10.216.8.202 with HTTP; Sun, 19 Oct 2014 18:35:55 -0700 (PDT) Date: Sun, 19 Oct 2014 18:35:55 -0700 Message-ID: From: Ca By To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7bea3de65e33ab0505d0bc69 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3uUqVjBvRlyodmzXYE-UL3OadOk Cc: "rtcweb@ietf.org" Subject: [rtcweb] FEC -- was Re: Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 01:36:19 -0000 --047d7bea3de65e33ab0505d0bc69 Content-Type: text/plain; charset=UTF-8 On Sunday, October 19, 2014, Bernard Aboba wrote: > Alex said: > > "I don't think apple will make a statement, but I remember reading that > microsoft would support 264 (at least for media element playback) if it > is available on the system. Bernard / shijun, any comment about which > codec would be used for ORTC/WebRTC?" > > [BA] Microsoft, Apple, Cisco, Blackberry, Ericsson and others have > previously co-authored an H.264 MTI proposal: > https://tools.ietf.org/html/draft-burman-rtcweb-h264-proposal > > Even though that proposal expires next week, we still believe it is > possible for an H.264 encoder/decoder to serve as a foundation for interoperability > between independent implementations. However, choosing an MTI codec and > specifying aspects of the codec is not enough. On wireless networks > (bursty) packet loss is common, so it is important to specify transport > aspects and robustness > > Bernard, Regarding packet loss in wireless networks and FEC, can you be more specific? It would be best if this problem was clearly articulated. Afaik, various flavors of 802.11 as well as UMTS and LTE all support L2 FEC. And, in the case of UMTS and LTE , all packets are retransmitted until the end point acknowledges the packet has been received. That said, it would be imprudent to put those functions again into L4 or L7. CB > measures. This would include an MTI FEC scheme and bandwidth estimation > techniques, as well as use of codec-specific feedback messages. > > In terms of what needs to be done, there is work needed on the rtp-usage > document (such as addressing the MTI FEC scheme), draft-ietf-rtcweb-video, > etc. Focussing on another MTI debate at this time could make it difficult > to make major progress before IETF 92. > > > If instead of tackling the hard problems, we spend our precious time on > yet another MTI debate, this will not satisfy customers who have burned > before. From past experience, they know that if interoperability issues > are not addressed *early on*, patching things up after the fact can be > difficult and time consuming. Yet that is *exactly* where we are headed. > > On Sun, Oct 19, 2014 at 11:46 AM, Alexandre GOUAILLARD < > agouaillard@gmail.com > > wrote: > >> @watson >> >> I would prefer the ISO process to see through before deciding. That's why >> I keep bothering harald for news at every meeting ;-) If for any reason it >> does not happen, we're back where we were when we did the last pool. >> Nobody has sued .... yet, does not mean there is no IP risk. Actually, >> there were at least 3 counts of nokia suing, but the three cases were >> negotiated and the result is not available to the public. (here >> >> ) >> >> @jonathan >> >> Point taken, I hadn't thought about the implications of H264 hardware >> acceleration. If indeed it leverages the need to get a license, that makes >> the situation better. Would that be enough ...? We could map all the cases >> and see what is left to be dealt with. In any case, deciding about 264 >> without looking at 265 seems shortsighted, and I am not aware of any >> binary, or hardware acceleration support available for 265 yet (even though >> iPhone 6 claims to supports 265 acc in its specs, I'm not aware of API that >> would allow native app to leverage this capacity). >> >> Correct me if I'm wrong or if I'm missing anything (anyone): >> >> -- desktop browsers -- >> - firefox, let's assume the 264 binary is used. It also supports VP8. >> - chrome on desktop supports vp8 but not 264 (as far as webrtc is >> concerned, the media element supports 264 playback). >> - what about IE / Safari ? I don't think apple will make a statement, but >> I remember reading that microsoft would support 264 (at least for media >> element playback) if it is available on the system. Bernard / shijun, any >> comment about which codec would be used for ORTC/webRTC? >> >> -- mobile browsers -- >> - no firefox on iOS. What about the android version, what does it support? >> - chrome supports only VP8, and can't support webRTC on iOS anyway (even >> though justin is working on a audio-only, API-injection-in-webkit solution). >> - opera? >> >> -- mobile native -- >> - iOS 8+ has system API for hw acc 264 >> - android has system API for both hw acc 264 and VP8 (is it true?) >> - the webrtc.org stack does not support 264 even though kaiduan die from >> blackberry provided a patch for this >> - the ericson's openwebrtc stack supports 264 in multiple ways (does it >> support hw acc?) but lack support for Windows and data channel. >> >> -- Others -- >> - lots of MCUs / SFUs / Gateways would need 264 in more cases than just >> the interoperability between webrtc and SIP, and I'm not sure the cisco >> binaries can be used there. >> >> On Mon, Oct 20, 2014 at 2:13 AM, Jonathan Rosenberg > > wrote: >> >>> @Alexandre - you say "Today, nothing has changed with respect to those >>> two items (even though providing open264 royalties and absorbing the >>> license cost for some platforms might have been a set in the right >>> direction). ". But, as you say, the availability of Firefox with H264 is a >>> change (previously it was not yet available); the fact that Cisco has in >>> fact fronted the cost is a change (at the last meeting some were skeptical >>> this would happen, but it has). The other big news was IOS8, which now >>> enables apps to access H264 and Apple pays the cost. Last time, the lack of >>> a solution on IOS was a big deal. That is also now, no longer an issue. As >>> such I think there are material changes. >>> >>> >>> On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD < >>> agouaillard@gmail.com >>> > wrote: >>> >>>> @jonathan, >>>> >>>> while you are right and availability of 264 implementation or hardware >>>> acceleration has improved, it has never been reported as a problem in the >>>> previous pool by anyone. The 264 royalties, and the VP8 IP risks were, >>>> AFAIR, the main reasons used by individuals to justify their positions. >>>> Today, nothing has changed with respect to those two items (even though >>>> providing open264 royalties and absorbing the license cost for some >>>> platforms might have been a set in the right direction). This is why I >>>> think the conditions are not met for a consensus to be reached. >>>> >>>> Alex. >>>> >>>> >>>> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba < >>>> bernard.aboba@gmail.com >>>> > wrote: >>>> >>>>> "And its one of the issues holding up wider adoption of the technology" >>>>> >>>>> [BA] Specifying an MTI encoder/decoder is not sufficient for >>>>> interoperability. It is also necessary to specify the transport in enough >>>>> detail to allow independent implementations that interoperate well enough >>>>> to be usable in a wide variety of scenarios, including wireless networks >>>>> where loss is commonly experienced. >>>>> >>>>> We made the mistake of having an MTI discussion previously with not >>>>> enough details on that subject, particularly with respect to H.264. >>>>> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. >>>>> >>>>> So if we are to have the discussion again, it should occur in the >>>>> context of detailed specifications and interoperability reports. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg < >>>>> jdrosen@jdrosen.net >>>>> > wrote: >>>>> >>>>>> I'm in favor of taking another run at this. >>>>>> >>>>>> The working group has repeatedly said that an MTI codec is something >>>>>> we need to produce. And its one of the issues holding up wider adoption of >>>>>> the technology (not the only one for sure). >>>>>> >>>>>> And things have changed since the last meeting, a year ago now >>>>>> (November in Vancouver). Cisco's open264 plugin shipped and now just >>>>>> recently is integrated into Firefox. iOS8 shipped with APIs for H264. There >>>>>> are other things worth noting. Will this change the minds of everyone? >>>>>> Surely not. Will it sway enough for us to achieve rough consensus? Maybe. >>>>>> IMHO - worth finding out. >>>>>> >>>>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < >>>>>> agouaillard@gmail.com >>>>>> > wrote: >>>>>> >>>>>>> +1 to not having MTI codec discussion unless some progress has been >>>>>>> made on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that >>>>>>> there was no change on the members position. >>>>>>> >>>>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand < >>>>>>> harald@alvestrand.no >>>>>>> > wrote: >>>>>>> >>>>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>>>>>> >>>>>>>>> One thing we could do instead of wasting time on MTI is to >>>>>>>>> actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so >>>>>>>>> we could actually interoperate regardless of the codec. >>>>>>>>> >>>>>>>> >>>>>>>> The big argument for an MTI is actually the one stated in >>>>>>>> -overview: It guards against interoperability failure. >>>>>>>> >>>>>>>> I would like to have an ecosystem where one can field a box, >>>>>>>> connect it to everything else, and run well for *some* level of "well" - >>>>>>>> and I would prefer that ecosystem to be one where it's possible to field >>>>>>>> the box without making prior arrangements with anyone about licenses. >>>>>>>> >>>>>>>> This argument hasn't changed one whit since last time we discussed >>>>>>>> it. And I don't see much movement on the specifics of the proposals either. >>>>>>>> >>>>>>>> We'll have to interoperate well with the codecs we field. So using >>>>>>>> some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 >>>>>>>> isn't finished either. There's one sentence that needs to be removed.) >>>>>>>> >>>>>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But >>>>>>>> I'd prefer to re-discuss based on the knowledge that some significant >>>>>>>> players have actually changed their minds. >>>>>>>> >>>>>>>> At the moment, I don't see signs that any of the poll respondents >>>>>>>> have said "I have changed my mind". >>>>>>>> >>>>>>>> Harald >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson < >>>>>>>>>> martin.thomson@gmail.com >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 16 October 2014 14:17, Matthew Kaufman >>>>>>>>>> > wrote: >>>>>>>>>>> And that's because something substantive has changed, or simply >>>>>>>>>>> because >>>>>>>>>>> wasting the WG time on this again is more entertaining than >>>>>>>>>>> actually >>>>>>>>>>> finishing a specification that can be independently implemented >>>>>>>>>>> by all >>>>>>>>>>> browser vendors? (A specification that we are nowhere near >>>>>>>>>>> having, as far as >>>>>>>>>>> I can tell) >>>>>>>>>>> >>>>>>>>>> Personally, I've found the reprieve from this fight refreshing. >>>>>>>>>> And >>>>>>>>>> it would appear that we've made some real progress as a result. >>>>>>>>>> I'd >>>>>>>>>> suggest that if we don't have new information, we continue to >>>>>>>>>> spend >>>>>>>>>> our time productively. If we can't find topics to occupy our >>>>>>>>>> meeting >>>>>>>>>> agenda time, then maybe we can free an agenda slot. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Alex. Gouaillard, PhD, PhD, MBA >>>>>>> >>>>>>> ------------------------------------------------------------------------------------ >>>>>>> CTO - Temasys Communications, S'pore / Mountain View >>>>>>> President - CoSMo Software, Cambridge, MA >>>>>>> >>>>>>> ------------------------------------------------------------------------------------ >>>>>>> sg.linkedin.com/agouaillard >>>>>>> >>>>>>> - >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> rtcweb mailing list >>>>>>> rtcweb@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jonathan Rosenberg, Ph.D. >>>>>> jdrosen@jdrosen.net >>>>>> >>>>>> http://www.jdrosen.net >>>>>> >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Alex. Gouaillard, PhD, PhD, MBA >>>> >>>> ------------------------------------------------------------------------------------ >>>> CTO - Temasys Communications, S'pore / Mountain View >>>> President - CoSMo Software, Cambridge, MA >>>> >>>> ------------------------------------------------------------------------------------ >>>> sg.linkedin.com/agouaillard >>>> >>>> - >>>> >>>> >>> >>> >>> -- >>> Jonathan Rosenberg, Ph.D. >>> jdrosen@jdrosen.net >>> >>> http://www.jdrosen.net >>> >> >> >> >> -- >> Alex. Gouaillard, PhD, PhD, MBA >> >> ------------------------------------------------------------------------------------ >> CTO - Temasys Communications, S'pore / Mountain View >> President - CoSMo Software, Cambridge, MA >> >> ------------------------------------------------------------------------------------ >> sg.linkedin.com/agouaillard >> >> - >> >> > --047d7bea3de65e33ab0505d0bc69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, October 19, 2014, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Alex said:

"I don't think apple will make a statement, but I remembe= r reading that microsoft would support 264 (at least for media element play= back)=C2=A0if it is available on the system.=C2=A0 Bernard / shijun,= any comment about which codec would be used for ORTC/WebRTC?"

[BA] Microsoft, Apple, Cisco, Blackberry, Ericsson and others have previ= ously co-authored an H.264 MTI proposal: https://tools.iet= f.org/html/draft-burman-rtcweb-h264-proposal

Even though that proposal expires next week, we still believe it i= s possible for an H.264 encoder/decoder to serve as a foundation for interoperability between independent implementations. =C2=A0 However, choo= sing an MTI codec and specifying aspects of the codec is not enough.=C2=A0 = On wireless networks (bursty) packet loss is common, so it is important to = specify transport aspects and robustness=C2=A0

Bernard,

Regarding packet loss in wireless n= etworks=C2=A0and FEC,=C2=A0 can you be more specific?

<= div>It would be best if this problem was clearly articulated. Afaik, variou= s flavors of=C2=A0802.11 as well as UMTS and LTE all support L2 FEC. And, i= n the case of UMTS and LTE ,=C2=A0all packets are retransmitted until the e= nd point acknowledges the packet has been received.=C2=A0

That said, it would be imprudent to put those functions again into = L4 or L7.=C2=A0

CB

measures.=C2=A0 This would include an MTI FEC sche= me and bandwidth estimation techniques, as well as use of codec-specific fe= edback messages.=C2=A0

In terms of what needs to be done, there is work needed on the rtp-usage= document (such as addressing the MTI FEC scheme), =C2=A0draft-ietf-rtcweb-= video, etc.=C2=A0 Focussing on another MTI debate at this time could make i= t difficult to make major progress before IETF 92.=C2=A0=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

If instead of tackling the hard problems, we spend our precious time on = yet another MTI debate, this will not satisfy customers who have burned bef= ore.=C2=A0 From past experience, they know that if interoperability issues = are not addressed *early on*, patching things up after the fact can be diff= icult and time consuming.=C2=A0 Yet that is *exactly* where we are headed.= =C2=A0


O= n Sun, Oct 19, 2014 at 11:46 AM, Alexandre GOUAILLARD <= ;agouaillard@gmail.com> wrote:
@watson

I = would prefer the ISO process to see through before deciding. That's why= I keep bothering harald for news at every meeting ;-) If for any reason it= does not happen, we're back where we were when we did the last pool.
Nobody has sued .... yet, does not mean there is no IP risk. Actua= lly, there were at least 3 counts of nokia suing, but the three cases were = negotiated and the result is not available to the public. (here)

@jonathan
Point taken, I hadn't thought about the implications of H26= 4 hardware acceleration. If indeed it leverages the need to get a license, = that makes the situation better. Would that be enough ...? We could map all= the cases and see what is left to be dealt with. In any case, deciding abo= ut 264 without looking at 265 seems shortsighted, and I am not aware of any= binary, or hardware acceleration support available for 265 yet (even thoug= h iPhone 6 claims to supports 265 acc in its specs, I'm not aware of AP= I that would allow native app to leverage this capacity).=C2=A0
<= br>
Correct me if I'm wrong or if I'm missing anything (a= nyone):

-- desktop browsers --
- fir= efox, let's assume the 264 binary is used. It also supports VP8.
<= div>- chrome on desktop supports vp8 but not 264 (as far as webrtc is conce= rned, the media element supports 264 playback).
- what about IE /= Safari ? I don't think apple will make a statement, but I remember rea= ding that microsoft would support 264 (at least for media element playback)= if it is available on the system. Bernard / shijun, any comment about whic= h codec would be used for ORTC/webRTC?

-- mobile b= rowsers --
- no firefox on iOS. What about the android version, w= hat does it support?
- chrome supports only VP8, and can't su= pport webRTC on iOS anyway (even though justin is working on a audio-only, = API-injection-in-webkit solution).
- opera?

<= div>-- mobile native --
- iOS 8+ has system API for hw acc 264
=
On Mon, Oct 20, 2014 at 2:13 AM, Jonathan Ro= senberg <jdrosen@jdrosen.net> wrote:
@Ale= xandre - you say "Today, nothing has changed with respect to those two items (even th= ough providing open264 royalties and absorbing the license cost for some pl= atforms might have been a set in the right direction).=C2=A0". But, as= you say, the availability of Firefox with H264 is a change (previously it = was not yet available); the fact that Cisco has in fact fronted the cost is= a change (at the last meeting some were skeptical this would happen, but i= t has). The other big news was IOS8, which now enables apps to access H264 = and Apple pays the cost. Last time, the lack of a solution on IOS was a big= deal. That is also now, no longer an issue. As such I think there are mate= rial changes.


<= div class=3D"gmail_quote">On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAI= LLARD <agouaillard@gmail.com<= /a>> wrote:
@j= onathan,

while you are right and availability of 264 imp= lementation or hardware acceleration has improved, it has never been report= ed as a problem in the previous pool by anyone. The 264 royalties, and the = VP8 IP risks were, AFAIR, the main reasons used by individuals to justify t= heir positions. Today, nothing has changed with respect to those two items = (even though providing open264 royalties and absorbing the license cost for= some platforms might have been a set in the right direction). This is why = I think the conditions are not met for a consensus to be reached.

Alex.


On Sun, Oct 19, 2014 at 11:43 PM, = Bernard Aboba <bernard.abob= a@gmail.com> wrote:
"And its one of the issues holding up wider adoption o= f the technology"

[BA] Specifying an MTI enc= oder/decoder is not sufficient for interoperability.=C2=A0 It is also neces= sary to specify the transport in enough detail to allow independent impleme= ntations that interoperate well enough to be usable in a wide variety of sc= enarios, including wireless networks where loss is commonly experienced. = =C2=A0

We made the mistake of having an MTI discus= sion previously with not enough details on that subject, particularly with = respect to H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy= at best. =C2=A0

So if we are to have the discussi= on again, it should occur in the context of detailed specifications and int= eroperability reports.

=C2=A0

=
=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> w= rote:
I'm in favor o= f taking another run at this.

The working group has repe= atedly said that an MTI codec is something we need to produce. And its one = of the issues holding up wider adoption of the technology (not the only one= for sure).

And things have changed since the last= meeting, a year ago now (November in Vancouver). Cisco's open264 plugi= n shipped and now just recently is integrated into Firefox. iOS8 shipped wi= th APIs for H264. There are other things worth noting. Will this change the= minds of everyone? Surely not. Will it sway enough for us to achieve rough= consensus? Maybe. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:= 08 PM, Alexandre GOUAILLARD <= agouaillard@gmail.com> wrote:
+1 to not having MTI codec discussion unless some progr= ess has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing ha= rald's =C2=A0feeling that there was no change on the members position.= =C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestrand.no> wrote:
On 10/17/2014 12:02 AM, Bernard Aboba wr= ote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew= @matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 A= nd
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



<= /div>--
Alex. Gouaillard= , PhD, PhD, MBA
-------------------------------------------------------= -----------------------------
CTO - Temasys Communications, S'= ;pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------= ------------------

  • =

_______________________________________________
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





--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------




--
=


--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------


--047d7bea3de65e33ab0505d0bc69-- From nobody Sun Oct 19 19:18:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E281A1ABB for ; Sun, 19 Oct 2014 19:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3Z75S8jkPKb for ; Sun, 19 Oct 2014 19:18:49 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 831E41A1AA8 for ; Sun, 19 Oct 2014 19:18:49 -0700 (PDT) Received: from ppp14-2-4-184.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.4.184]) by ipmail04.adl6.internode.on.net with ESMTP; 20 Oct 2014 12:48:48 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 51FC9FFE82 for ; Mon, 20 Oct 2014 12:48:46 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kMqmixpo1ahF for ; Mon, 20 Oct 2014 12:48:45 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 656A6FFC07 for ; Mon, 20 Oct 2014 12:48:45 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 5229780470; Mon, 20 Oct 2014 12:48:45 +1030 (ACDT) Date: Mon, 20 Oct 2014 12:48:45 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141020021845.GC8092@hex.shelbyville.oz> References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qBv6dHchvI_CCH-0e-NajAh0UdM Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 02:18:51 -0000 On Mon, Oct 20, 2014 at 01:20:04AM +0000, Cavigioli, Chris wrote: > This is a complex topic with many network factors in play. LTE > operators in 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS > – AMR transcoding in the network imposes an additional 211.5 ms on top > of that, just for audio. Optionally using AMR in WebRTC, those 211.5 > ms can be eliminated, delivering a superior end-user experience. That seems like LTE's problem, not ours. If you start with a codec like Opus where the maximum native frame size is 60ms and manage to engineer a solution that blows that out to near 400ms, we'd certainly have to applaud your, uh, innovation. > CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a > good WebRTC – LTE interop experience, emerging WebRTC systems must > accommodate MTI codecs already deployed in the LTE domain and in > mobile operating systems, namely AMR/AMR-WB and H.264. You conclude that since LTE sucks, WebRTC ought to suck too? That seems like a strange direction to move in. 150ms is already ample delay on its own to create a horrible user experience. The aim of WebRTC was to create a standard solution that doesn't suck. If LTE thinks it won't be able to compete with that, but considers interoperating with it to be important, maybe it's time LTE thought more about deploying a codec that's actually up to the job than about protecting the royalty revenues of its voting group ... If 150ms is your idea of a "superior end-user experience", then maybe people who want a satisfactory user experience will simply avoid using LTE at all, and then this won't be a problem for them, or us, at all. Just sayin' From nobody Sun Oct 19 21:24:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8E31A1BC6 for ; Sun, 19 Oct 2014 21:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLs4Oy3rKA9b for ; Sun, 19 Oct 2014 21:24:35 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742141A6F7E for ; Sun, 19 Oct 2014 21:24:34 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so4461521wgh.23 for ; Sun, 19 Oct 2014 21:24:33 -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=Dcfg3MBbriA17g5bGZ5irI6sxgrHgDuJd/Gv3MTivxo=; b=BQWYiWJuY0KeKY3I17wYVrXVDVrhjoSinbQKrHBdN6xJ8X8qvpbRI+QUuYKKHaMOZ6 XQHfQSW27ApV1++vvsuFVu6BRPG6/5XrFPIDHDMW3llQvHupyAlo05NZsoh1JfSpnhRu iZHHUdwRJyvK9JVfzApjIjCPYMc80Z99JzF2hbxINCarUBUEQy8ISUd6xI9aDbRGzdcR OuNF1ZUoA3WT5m89aHtfWh1o278iqNqcwTySHFPPJNQFOt1mKCXrvLN6gZ8baHj/NLTs OKEBsRrNPwxKqBMvivDefCbzytL5J47BM6qggRWFIfgZ9w4xmdEbBGSOwZ1l78BMXXm7 dEtg== MIME-Version: 1.0 X-Received: by 10.195.12.76 with SMTP id eo12mr29958207wjd.22.1413779073039; Sun, 19 Oct 2014 21:24:33 -0700 (PDT) Received: by 10.216.8.202 with HTTP; Sun, 19 Oct 2014 21:24:32 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> Date: Sun, 19 Oct 2014 21:24:32 -0700 Message-ID: From: Ca By To: "Cavigioli, Chris" Content-Type: multipart/alternative; boundary=047d7bfceb4c70846a0505d317f2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hzSwaKo2r7aAkUxMSPziVIqyZ9E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 04:24:39 -0000 --047d7bfceb4c70846a0505d317f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, October 19, 2014, Cavigioli, Chris wrote: > Harald said: > > =E2=80=9CWe made the mistake of having an MTI discussion previously with = not > enough details on that subject=E2=80=A6=E2=80=9D > > > > We didn=E2=80=99t have quantitative data earlier for a data-driven decisi= on. > Future Web =E2=80=93 LTE interop is important. A group of us in GSMA hav= e been > looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based > voice/video/messaging), specifically looking at user experience impact of > latency introduced by added in-network transcoding. GSMA has approved th= e > whitepaper and it is being prepared for public distribution. > > > > WebRTC =E2=80=93 LTE transcoding is now MANDATORY because of =E2=80=9CWeb= RTC Audio Codec > and Processing Requirements=E2=80=9D. > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio > codecs in WebRTC and in LTE are dissimilar. Thus, REGARDLESS of the vide= o > codecs, there is already a significant degradation imposed on Web =E2=80= =93 LTE > links if only MTI codecs are used. The only systems to avoid this are > those which implement OPTIONAL audio codecs to be transcoder-free with > LTE. The same can apply for video codecs. > > > > The GSMA whitepaper refers to: > > 1. Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by > 3GPP SA4 in August 2014. To paraphrase, performance objectives for maxim= um > VoLTE device delays in error and jitter free conditions and AMR speech > codec operation, the sum of the UE delays in sending and receiving > directions (TS + TR) should be =E2=89=A4 150ms. If this performance objec= tive > cannot be met, the sum of the UE delays in sending and receiving directio= ns > (TS + TR) shall in any case be =E2=89=A4 190ms. > > 2. OPUS =E2=80=93 AMR transcoding adds an additional 211.5 ms > implementation-agnostic (TS + TR) delay, including 40 ms for jitter > buffer and 40 ms for discontinuous reception (DRX). > > 3. To put these numbers in perspective, it is in general desirable to > minimize UE delays to ensure low enough end-to-end delays and hence a goo= d > conversational experience. Increasing delay causes people to double-talk > making conversations increasingly frustrating. Guidance to stay below 40= 0 > ms maximum one-way delay is found in ITU-T Recommendation G.114 and the > computational E-model is in ITU-T Recommendation G.107. > > > > This is a complex topic with many network factors in play. LTE operators > in 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS =E2=80=93 AM= R > transcoding in the network imposes an additional 211.5 ms on top of that, > just for audio. Optionally using AMR in WebRTC, those 211.5 ms can be > eliminated, delivering a superior end-user experience. > > > > CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a good > WebRTC =E2=80=93 LTE interop experience, emerging WebRTC systems must acc= ommodate > MTI codecs already deployed in the LTE domain and in mobile operating > systems, namely AMR/AMR-WB and H.264. > > > > POSITION: To be clear, several Intel SoCs launched at MWC this year for > smartphones and tablets support both VP8 and H.264 hardware encode and > decode =E2=80=93 so Intel is codec-neutral in this MTI debate. Additiona= lly, Intel > has high-performance solutions for transcoding. However, we wish to info= rm > the industry, with quantitative data, about impact to end-user experience > of mandating such transcoding so IETF can make a data-driven decision on > video codecs as well as reflect on the impact of already having mandated > transcoding on the audio side. > > > > Chris, My expectation is that something acceptable will be negotiated. And, these LTE smartphones can and do support a variety of codecs, as you noted. AMR and h264 are tied to walled garden mobile telco IMS mumbo jumbo, which has little to do with webrtc, and webrtc has a lot to do with an open internet. My guess is the IMS will change to interop with webrtc in an effort to stay relevant. CB > Chris Cavigioli > > Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile > and Communications Group (MCG) > > +1 (415) 254-4545 mobile > > +1 (408) 653-8348 desk > > +1 (408) 884-2400 fax > > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review or distribution by others i= s > strictly prohibited. If you are not the intended recipient, please contac= t > the sender and delete all copies. > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org > ] *On Behalf Of = *Bernard > Aboba > *Sent:* Sunday, October 19, 2014 2:29 PM > *To:* Harald Alvestrand > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Harald said: > > > > "Bernard, > > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad....." > > > > [BA] I agree that the lack of interoperability is largely "codec > independent": that is, implementations based on different mechanisms fo= r > congestion control, repair, etc. will exhibit interoperability problems, > regardless of the codec chosen. The real test for RTCWEB will be to mov= e > beyond "interoperability of implementations sharing source code" to > "interoperability of independent implementations, based on open standards= ". > > > > > On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand > wrote: > > On 10/19/2014 05:43 PM, Bernard Aboba wrote: > > "And its one of the issues holding up wider adoption of the technology" > > > > [BA] Specifying an MTI encoder/decoder is not sufficient for > interoperability. It is also necessary to specify the transport in enoug= h > detail to allow independent implementations that interoperate well enough > to be usable in a wide variety of scenarios, including wireless networks > where loss is commonly experienced. > > > Bernard, > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad..... > > > > > > > We made the mistake of having an MTI discussion previously with not enoug= h > details on that subject, particularly with respect to H.264. > draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > > > > So if we are to have the discussion again, it should occur in the context > of detailed specifications and interoperability reports. > > > > > > > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: > > I'm in favor of taking another run at this. > > > > The working group has repeatedly said that an MTI codec is something we > need to produce. And its one of the issues holding up wider adoption of t= he > technology (not the only one for sure). > > > > And things have changed since the last meeting, a year ago now (November > in Vancouver). Cisco's open264 plugin shipped and now just recently is > integrated into Firefox. iOS8 shipped with APIs for H264. There are other > things worth noting. Will this change the minds of everyone? Surely not. > Will it sway enough for us to achieve rough consensus? Maybe. IMHO - wort= h > finding out. > > > > On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < > agouaillard@gmail.com > > wrote: > > +1 to not having MTI codec discussion unless some progress has been made > on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that ther= e > was no change on the members position. > > > > On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: > > On 10/17/2014 12:02 AM, Bernard Aboba wrote: > > One thing we could do instead of wasting time on MTI is to actually make > progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could > actually interoperate regardless of the codec. > > > The big argument for an MTI is actually the one stated in -overview: It > guards against interoperability failure. > > I would like to have an ecosystem where one can field a box, connect it t= o > everything else, and run well for *some* level of "well" - and I would > prefer that ecosystem to be one where it's possible to field the box > without making prior arrangements with anyone about licenses. > > This argument hasn't changed one whit since last time we discussed it. An= d > I don't see much movement on the specifics of the proposals either. > > We'll have to interoperate well with the codecs we field. So using some > time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn= 't > finished either. There's one sentence that needs to be removed.) > > I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd > prefer to re-discuss based on the knowledge that some significant players > have actually changed their minds. > > At the moment, I don't see signs that any of the poll respondents have > said "I have changed my mind". > > Harald > > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: > > On 16 October 2014 14:17, Matthew Kaufman > wrote: > And that's because something substantive has changed, or simply because > wasting the WG time on this again is more entertaining than actually > finishing a specification that can be independently implemented by all > browser vendors? (A specification that we are nowhere near having, as far > as > I can tell) > > Personally, I've found the reprieve from this fight refreshing. And > it would appear that we've made some real progress as a result. I'd > suggest that if we don't have new information, we continue to spend > our time productively. If we can't find topics to occupy our meeting > agenda time, then maybe we can free an agenda slot. > > _______________________________________________ > 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 > > > > > > -- > > Alex. Gouaillard, PhD, PhD, MBA > > > -------------------------------------------------------------------------= ----------- > > CTO - Temasys Communications, S'pore / Mountain View > > President - CoSMo Software, Cambridge, MA > > > -------------------------------------------------------------------------= ----------- > > sg.linkedin.com/agouaillard > > =C2=B7 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > 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 > > > > -- > > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --047d7bfceb4c70846a0505d317f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, October 19, 2014, Cavigioli, Chris <chris.cavigioli@intel.com> wrote:

Harald said:=C2=A0

=E2=80=9CWe made the mistake of having an MTI discus= sion previously with not enough details on that subject=E2=80=A6=E2=80=9D

=C2=A0=

We didn=E2=80=99t have quan= titative data earlier for a data-driven decision.=C2=A0 Future Web =E2=80= =93 LTE interop is important.=C2=A0 A group of us in GSMA have been looking= at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messagin= g), specifically looking at user experience impact of latency introduced by= added in-network transcoding.=C2=A0 GSMA has approved the whitepaper and i= t is being prepared for public distribution.=C2=A0

=C2=A0=

WebRTC =E2=80=93 LTE transc= oding is now MANDATORY because of =E2=80=9CWebRTC Audio Codec and Processin= g Requirements=E2=80=9D. http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where M= TI audio codecs in WebRTC and in LTE are dissimilar.=C2=A0 Thus, REGARDLESS= of the video codecs, there is already a significant degradation imposed on Web =E2=80=93 LTE links if only MTI codecs are used.=C2=A0 The = only systems to avoid this are those which implement OPTIONAL audio codecs = to be transcoder-free with LTE.=C2=A0 The same can apply for video codecs.<= u>

=C2=A0=

The GSMA whitepaper refers = to:

1.=C2=A0=C2=A0=C2=A0=C2=A0 Quantitative voice-ove= r-LTE (VoLTE) delay limits were agreed-to by 3GPP SA4 in August 2014.=C2=A0= To paraphrase, performance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec ope= ration, the sum of the UE delays in sending and receiving directions (TS + TR) should be =E2=89=A4 150ms. If this performance ob= jective cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR)= shall in any case be =E2=89=A4 190ms.

2.=C2=A0=C2=A0=C2=A0=C2=A0 OPUS =E2=80=93 AMR tra= nscoding adds an additional 211.5 ms implementation-agnostic (TS= + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.=C2=A0=C2=A0=C2=A0=C2=A0 To put these numbers i= n perspective, it is in general desirable to minimize UE delays to ensure l= ow enough end-to-end delays and hence a good conversational experience.=C2=A0 Increasing delay causes people to double-talk making con= versations increasingly frustrating.=C2=A0 Guidance to stay below 400 ms ma= ximum one-way delay is found in ITU-T Recommendation G.114 and the computat= ional E-model is in ITU-T Recommendation G.107.

=C2=A0=

This is a complex topic wit= h many network factors in play.=C2=A0 LTE operators in 3GPP seek UE delays = (TS + TR) around 150 ms.=C2=A0 Adding OPUS =E2=80=93 AMR transcoding in the network imposes an additional 211.5 ms on top of th= at, just for audio.=C2=A0 Optionally using AMR in WebRTC, those 211.5 ms ca= n be eliminated, delivering a superior end-user experience.=C2=A0

=C2=A0=

CONCLUSION: =C2=A0regardles= s of MTI codec choices in WebRTC, to provide a good WebRTC =E2=80=93 LTE in= terop experience, emerging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely= AMR/AMR-WB and H.264.

=C2=A0=

POSITION:=C2=A0 To be clear= , several Intel SoCs launched at MWC this year for smartphones and tablets = support both VP8 and H.264 hardware encode and decode =E2=80=93 so Intel is codec-neutral in this MTI debate.=C2=A0 Additionally, Intel has high-pe= rformance solutions for transcoding.=C2=A0 However, we wish to inform the i= ndustry, with quantitative data, about impact to end-user experience of man= dating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impact of a= lready having mandated transcoding on the audio side.<= /p>

=C2=A0=


Chris,

My expectation is that something acceptabl= e will be negotiated. And, these LTE smartphones can and do support a varie= ty of codecs, as you noted.=C2=A0

AMR and h264 are= tied to walled garden mobile telco IMS mumbo jumbo, which has little to do= with webrtc, and webrtc has a lot to do with an open internet.=C2=A0My gue= ss is the IMS will change to interop with webrtc in an effort to stay relev= ant.=C2=A0

CB=C2=A0

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group = (MCG)

+1 (415) 254-4545 mobile

+1 (408) 653-8348 desk<= /u>

+1 (408) 884-2400 fax

This e-mail may contain confi= dential and privileged material for the sole use of the intended recipient(= s).=C2=A0 Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delet= e all copies.

=C2=A0=

From: rtcweb [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan for MTI video codec?=

=C2=A0

Harald said:=C2=A0

=C2=A0

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....&qu= ot;

=C2=A0

[BA] =C2=A0I agree that the lack of interoperability= is largely "codec independent": =C2=A0 that is, implementations = based on different mechanisms for congestion control, repair, etc. will exh= ibit interoperability problems, regardless of the codec chosen. =C2=A0 The real test for RTCWEB will be to move beyond "inter= operability of implementations sharing source code" =C2=A0to "int= eroperability of independent implementations, based on open standards"= . =C2=A0=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand &= lt;harald@alvestrand.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:<= u>

"And its one of the issues holding up wider ado= ption of the technology"

=C2=A0

[BA] Specifying an MTI encoder/decoder is not suffic= ient for interoperability.=C2=A0 It is also necessary to specify the transp= ort in enough detail to allow independent implementations that interoperate= well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienc= ed.=C2=A0


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....




=C2=A0

We made the mistake of having an MTI discussion prev= iously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.= =C2=A0

=C2=A0

So if we are to have the discussion again, it should= occur in the context of detailed specifications and interoperability repor= ts.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrosen.net> wrote:=

I'm in favor of taking another run at this. <= /u>

=C2=A0

The working group has repeatedly said that an MTI co= dec is something we need to produce. And its one of the issues holding up w= ider adoption of the technology (not the only one for sure).<= /p>

=C2=A0

And things have changed since the last meeting, a ye= ar ago now (November in Vancouver). Cisco's open264 plugin shipped and = now just recently is integrated into Firefox. iOS8 shipped with APIs for H2= 64. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough fo= r us to achieve rough consensus? Maybe. IMHO - worth finding out.=

=C2=A0

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLAR= D <agouaillard@gmail.com> wrote:<= u>

+1 to not having MTI codec discussion unless some pr= ogress has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing= harald's =C2=A0feeling that there was no change on the members positio= n.=C2=A0

=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestrand.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:<= u>

One thing we could do instead of wasting time on MTI= is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-vi= deo, so we could actually interoperate regardless of the codec.


The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald





On Oct 16, 2014, at 2= :28 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)

Personally, I've found the reprieve from this fi= ght refreshing.=C2=A0 And
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



=C2=A0

--

Alex. Gouaillard, PhD,= PhD, MBA

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

CTO - Temasys Communic= ations, S'pore / Mountain View

President - CoSMo Soft= ware, Cambridge, MA

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

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0


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



=C2=A0

--


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

=C2=A0

=C2=A0<= /p> 

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

=C2=A0<= /p> 

-- 
Surveillance is pervasive. Go Dark.


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

=C2=A0

--047d7bfceb4c70846a0505d317f2-- From nobody Sun Oct 19 22:52:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806191A6F7E for ; Sun, 19 Oct 2014 22:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lpCNtMPL3ii for ; Sun, 19 Oct 2014 22:52:35 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4935B1A1B05 for ; Sun, 19 Oct 2014 22:52:35 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id lf12so3009474vcb.17 for ; Sun, 19 Oct 2014 22:52:34 -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; bh=FKnERibP7BJ8eyphcrrYjFkSTHFdcy48BXn1mNg/fUo=; b=V3YJiwlObqM6nkduTQc9zNmh6eWEeyh5ynrSYOuxqXZBNAp+5CywNXYzCjQXqIhyXJ azESekYIW/7eBwoYhbbk1U+7i85C7RPVwf3ie/f37Huoi3cqKSCDF1CCkcKfdM8XCpjS eD9LAh4eAKve1iE6a8NF+PbnJlZxqLQG6bzf3TtOR5GQl4O0pZd/6MvEHHcn7YxyZwf+ QNVdFx05O3Cv88tJ8kHM65bMEnog6rJrrDcp3ZhRgwZLyRk051Zqxn6WmYyeIOyv8FIc mgKJr+wid0y0OR7btS3ckvhws1YkJqdJ6EkbXGXcJPRL/+9WGdqw1GyoU18nSPLsYu1s wYqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FKnERibP7BJ8eyphcrrYjFkSTHFdcy48BXn1mNg/fUo=; b=m0fqGTyzJ+HCbtr2JbaSKgjvTw/At7ib6lbJ6arK8lXpm8ihj5AOZgX7BuEkPTcos7 JSRO2Nk3ENpqikzZWxXnuHB5ptcTOto85dSgrP49mmXwtvtIlOPdTVnkVlPUt5Yj8Gb0 1L34YCxi8deCtJcQ3iM7zn/HJfrswLiA7fCa7wVLkNmTsLJND4X1MEwHF7f3DEwTt8BD nH6v4r00ACenDJYZgkUZ78m4UtxGetG/nKixe70gUePJGtnmifVeGJr+YJAMXhotghVe G6sgucEj9xhIFV06ssBoUpJrydRVHnkCBs5mKCbEy43/5fufnkm7K1R2FvkK14i35GzB /svg== X-Gm-Message-State: ALoCoQmSrFfQutreIHNu5qYFnw1nIjdzWILLKUreUiGCRZjlfEa0fBgmrSHkX57ZzIbUX8H3Vx5e X-Received: by 10.220.77.196 with SMTP id h4mr21217613vck.14.1413784354216; Sun, 19 Oct 2014 22:52:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Sun, 19 Oct 2014 22:52:14 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> From: Justin Uberti Date: Sun, 19 Oct 2014 22:52:14 -0700 Message-ID: To: "Cavigioli, Chris" Content-Type: multipart/alternative; boundary=047d7b3a911c391d580505d4529a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g_wj-eIg7FTjmPQ5MjSyYI7M7ec Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 05:52:39 -0000 --047d7b3a911c391d580505d4529a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Looks like someone wants to have not just one, but two MTI codec discussions... On Sun, Oct 19, 2014 at 6:20 PM, Cavigioli, Chris wrote: > Harald said: > > =E2=80=9CWe made the mistake of having an MTI discussion previously with = not > enough details on that subject=E2=80=A6=E2=80=9D > > > > We didn=E2=80=99t have quantitative data earlier for a data-driven decisi= on. > Future Web =E2=80=93 LTE interop is important. A group of us in GSMA hav= e been > looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based > voice/video/messaging), specifically looking at user experience impact of > latency introduced by added in-network transcoding. GSMA has approved th= e > whitepaper and it is being prepared for public distribution. > > > > WebRTC =E2=80=93 LTE transcoding is now MANDATORY because of =E2=80=9CWeb= RTC Audio Codec > and Processing Requirements=E2=80=9D. > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio > codecs in WebRTC and in LTE are dissimilar. Thus, REGARDLESS of the vide= o > codecs, there is already a significant degradation imposed on Web =E2=80= =93 LTE > links if only MTI codecs are used. The only systems to avoid this are > those which implement OPTIONAL audio codecs to be transcoder-free with > LTE. The same can apply for video codecs. > > > > The GSMA whitepaper refers to: > > 1. Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by > 3GPP SA4 in August 2014. To paraphrase, performance objectives for maxim= um > VoLTE device delays in error and jitter free conditions and AMR speech > codec operation, the sum of the UE delays in sending and receiving > directions (TS + TR) should be =E2=89=A4 150ms. If this performance objec= tive > cannot be met, the sum of the UE delays in sending and receiving directio= ns > (TS + TR) shall in any case be =E2=89=A4 190ms. > > 2. OPUS =E2=80=93 AMR transcoding adds an additional 211.5 ms > implementation-agnostic (TS + TR) delay, including 40 ms for jitter > buffer and 40 ms for discontinuous reception (DRX). > > 3. To put these numbers in perspective, it is in general desirable to > minimize UE delays to ensure low enough end-to-end delays and hence a goo= d > conversational experience. Increasing delay causes people to double-talk > making conversations increasingly frustrating. Guidance to stay below 40= 0 > ms maximum one-way delay is found in ITU-T Recommendation G.114 and the > computational E-model is in ITU-T Recommendation G.107. > > > > This is a complex topic with many network factors in play. LTE operators > in 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS =E2=80=93 AM= R > transcoding in the network imposes an additional 211.5 ms on top of that, > just for audio. Optionally using AMR in WebRTC, those 211.5 ms can be > eliminated, delivering a superior end-user experience. > > > > CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a good > WebRTC =E2=80=93 LTE interop experience, emerging WebRTC systems must acc= ommodate > MTI codecs already deployed in the LTE domain and in mobile operating > systems, namely AMR/AMR-WB and H.264. > > > > POSITION: To be clear, several Intel SoCs launched at MWC this year for > smartphones and tablets support both VP8 and H.264 hardware encode and > decode =E2=80=93 so Intel is codec-neutral in this MTI debate. Additiona= lly, Intel > has high-performance solutions for transcoding. However, we wish to info= rm > the industry, with quantitative data, about impact to end-user experience > of mandating such transcoding so IETF can make a data-driven decision on > video codecs as well as reflect on the impact of already having mandated > transcoding on the audio side. > > > > Chris Cavigioli > > Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile > and Communications Group (MCG) > > +1 (415) 254-4545 mobile > > +1 (408) 653-8348 desk > > +1 (408) 884-2400 fax > > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review or distribution by others i= s > strictly prohibited. If you are not the intended recipient, please contac= t > the sender and delete all copies. > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Bernard > Aboba > *Sent:* Sunday, October 19, 2014 2:29 PM > *To:* Harald Alvestrand > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Harald said: > > > > "Bernard, > > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad....." > > > > [BA] I agree that the lack of interoperability is largely "codec > independent": that is, implementations based on different mechanisms fo= r > congestion control, repair, etc. will exhibit interoperability problems, > regardless of the codec chosen. The real test for RTCWEB will be to mov= e > beyond "interoperability of implementations sharing source code" to > "interoperability of independent implementations, based on open standards= ". > > > > > On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand > wrote: > > On 10/19/2014 05:43 PM, Bernard Aboba wrote: > > "And its one of the issues holding up wider adoption of the technology" > > > > [BA] Specifying an MTI encoder/decoder is not sufficient for > interoperability. It is also necessary to specify the transport in enoug= h > detail to allow independent implementations that interoperate well enough > to be usable in a wide variety of scenarios, including wireless networks > where loss is commonly experienced. > > > Bernard, > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad..... > > > > > > > We made the mistake of having an MTI discussion previously with not enoug= h > details on that subject, particularly with respect to H.264. > draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > > > > So if we are to have the discussion again, it should occur in the context > of detailed specifications and interoperability reports. > > > > > > > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: > > I'm in favor of taking another run at this. > > > > The working group has repeatedly said that an MTI codec is something we > need to produce. And its one of the issues holding up wider adoption of t= he > technology (not the only one for sure). > > > > And things have changed since the last meeting, a year ago now (November > in Vancouver). Cisco's open264 plugin shipped and now just recently is > integrated into Firefox. iOS8 shipped with APIs for H264. There are other > things worth noting. Will this change the minds of everyone? Surely not. > Will it sway enough for us to achieve rough consensus? Maybe. IMHO - wort= h > finding out. > > > > On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < > agouaillard@gmail.com> wrote: > > +1 to not having MTI codec discussion unless some progress has been made > on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that ther= e > was no change on the members position. > > > > On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: > > On 10/17/2014 12:02 AM, Bernard Aboba wrote: > > One thing we could do instead of wasting time on MTI is to actually make > progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could > actually interoperate regardless of the codec. > > > The big argument for an MTI is actually the one stated in -overview: It > guards against interoperability failure. > > I would like to have an ecosystem where one can field a box, connect it t= o > everything else, and run well for *some* level of "well" - and I would > prefer that ecosystem to be one where it's possible to field the box > without making prior arrangements with anyone about licenses. > > This argument hasn't changed one whit since last time we discussed it. An= d > I don't see much movement on the specifics of the proposals either. > > We'll have to interoperate well with the codecs we field. So using some > time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn= 't > finished either. There's one sentence that needs to be removed.) > > I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd > prefer to re-discuss based on the knowledge that some significant players > have actually changed their minds. > > At the moment, I don't see signs that any of the poll respondents have > said "I have changed my mind". > > Harald > > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: > > On 16 October 2014 14:17, Matthew Kaufman wrote: > And that's because something substantive has changed, or simply because > wasting the WG time on this again is more entertaining than actually > finishing a specification that can be independently implemented by all > browser vendors? (A specification that we are nowhere near having, as far > as > I can tell) > > Personally, I've found the reprieve from this fight refreshing. And > it would appear that we've made some real progress as a result. I'd > suggest that if we don't have new information, we continue to spend > our time productively. If we can't find topics to occupy our meeting > agenda time, then maybe we can free an agenda slot. > > _______________________________________________ > 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 > > > > > > -- > > Alex. Gouaillard, PhD, PhD, MBA > > > -------------------------------------------------------------------------= ----------- > > CTO - Temasys Communications, S'pore / Mountain View > > President - CoSMo Software, Cambridge, MA > > > -------------------------------------------------------------------------= ----------- > > sg.linkedin.com/agouaillard > > =C2=B7 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > 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 > > > > -- > > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > 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 > > --047d7b3a911c391d580505d4529a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks like someone wants to have not just one, but two MTI= codec discussions...

On Sun, Oct 19, 2014 at 6:20 PM, Cavigioli, Chris <chris= .cavigioli@intel.com> wrote:

Harald said:=C2=A0

=E2=80=9CWe made the mistake of having an MTI discus= sion previously with not enough details on that subject=E2=80=A6=E2=80=9D

=C2=A0=

We didn=E2=80=99t have quan= titative data earlier for a data-driven decision.=C2=A0 Future Web =E2=80= =93 LTE interop is important.=C2=A0 A group of us in GSMA have been looking= at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messagin= g), specifically looking at user experience impact of latency introduced by= added in-network transcoding.=C2=A0 GSMA has approved the whitepaper and i= t is being prepared for public distribution.=C2=A0

=C2=A0=

WebRTC =E2=80=93 LTE transc= oding is now MANDATORY because of =E2=80=9CWebRTC Audio Codec and Processin= g Requirements=E2=80=9D. http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where M= TI audio codecs in WebRTC and in LTE are dissimilar.=C2=A0 Thus, REGARDLESS= of the video codecs, there is already a significant degradation imposed on Web =E2=80=93 LTE links if only MTI codecs are used.=C2=A0 The = only systems to avoid this are those which implement OPTIONAL audio codecs = to be transcoder-free with LTE.=C2=A0 The same can apply for video codecs.<= u>

=C2=A0=

The GSMA whitepaper refers = to:

1.=C2=A0=C2=A0=C2=A0=C2=A0 Quantitative voice-ove= r-LTE (VoLTE) delay limits were agreed-to by 3GPP SA4 in August 2014.=C2=A0= To paraphrase, performance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec ope= ration, the sum of the UE delays in sending and receiving directions (TS + TR) should be =E2=89=A4 150ms. If this performance ob= jective cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR)= shall in any case be =E2=89=A4 190ms.

2.=C2=A0=C2=A0=C2=A0=C2=A0 OPUS =E2=80=93 AMR tra= nscoding adds an additional 211.5 ms implementation-agnostic (TS= + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.=C2=A0=C2=A0=C2=A0=C2=A0 To put these numbers i= n perspective, it is in general desirable to minimize UE delays to ensure l= ow enough end-to-end delays and hence a good conversational experience.=C2=A0 Increasing delay causes people to double-talk making con= versations increasingly frustrating.=C2=A0 Guidance to stay below 400 ms ma= ximum one-way delay is found in ITU-T Recommendation G.114 and the computat= ional E-model is in ITU-T Recommendation G.107.

=C2=A0=

This is a complex topic wit= h many network factors in play.=C2=A0 LTE operators in 3GPP seek UE delays = (TS + TR) around 150 ms.=C2=A0 Adding OPUS =E2=80=93 AMR transcoding in the network imposes an additional 211.5 ms on top of th= at, just for audio.=C2=A0 Optionally using AMR in WebRTC, those 211.5 ms ca= n be eliminated, delivering a superior end-user experience.=C2=A0

=C2=A0=

CONCLUSION: =C2=A0regardles= s of MTI codec choices in WebRTC, to provide a good WebRTC =E2=80=93 LTE in= terop experience, emerging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely= AMR/AMR-WB and H.264.

=C2=A0=

POSITION:=C2=A0 To be clear= , several Intel SoCs launched at MWC this year for smartphones and tablets = support both VP8 and H.264 hardware encode and decode =E2=80=93 so Intel is codec-neutral in this MTI debate.=C2=A0 Additionally, Intel has high-pe= rformance solutions for transcoding.=C2=A0 However, we wish to inform the i= ndustry, with quantitative data, about impact to end-user experience of man= dating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impact of a= lready having mandated transcoding on the audio side.<= /p>

=C2=A0=

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group = (MCG)

+1 (415) 254-454= 5 mobile

+1 (408) 653-834= 8 desk

+1 (408) 884-240= 0 fax

This e-mail may contain confi= dential and privileged material for the sole use of the intended recipient(= s).=C2=A0 Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delet= e all copies.

=C2=A0=

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?=

=C2=A0

Harald said:=C2=A0

=C2=A0

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....&qu= ot;

=C2=A0

[BA] =C2=A0I agree that the lack of interoperability= is largely "codec independent": =C2=A0 that is, implementations = based on different mechanisms for congestion control, repair, etc. will exh= ibit interoperability problems, regardless of the codec chosen. =C2=A0 The real test for RTCWEB will be to move beyond "inter= operability of implementations sharing source code" =C2=A0to "int= eroperability of independent implementations, based on open standards"= . =C2=A0=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:<= u>

"And its one of the issues holding up wider ado= ption of the technology"

=C2=A0

[BA] Specifying an MTI encoder/decoder is not suffic= ient for interoperability.=C2=A0 It is also necessary to specify the transp= ort in enough detail to allow independent implementations that interoperate= well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienc= ed.=C2=A0


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....




=C2=A0

We made the mistake of having an MTI discussion prev= iously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.= =C2=A0

=C2=A0

So if we are to have the discussion again, it should= occur in the context of detailed specifications and interoperability repor= ts.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrose= n.net> wrote:

I'm in favor of taking another run at this. <= /u>

=C2=A0

The working group has repeatedly said that an MTI co= dec is something we need to produce. And its one of the issues holding up w= ider adoption of the technology (not the only one for sure).<= /p>

=C2=A0

And things have changed since the last meeting, a ye= ar ago now (November in Vancouver). Cisco's open264 plugin shipped and = now just recently is integrated into Firefox. iOS8 shipped with APIs for H2= 64. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough fo= r us to achieve rough consensus? Maybe. IMHO - worth finding out.=

=C2=A0

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLAR= D <agouaillar= d@gmail.com> wrote:

+1 to not having MTI codec discussion unless some pr= ogress has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing= harald's =C2=A0feeling that there was no change on the members positio= n.=C2=A0

=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:<= u>

One thing we could do instead of wasting time on MTI= is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-vi= deo, so we could actually interoperate regardless of the codec.


The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald





On Oct 16, 2014, at 2= :28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at>= ; wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)

Personally, I've found the reprieve from this fi= ght refreshing.=C2=A0 And
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



=C2=A0

--

Alex. Gouaillard, PhD,= PhD, MBA

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

CTO - Temasys Communic= ations, S'pore / Mountain View

President - CoSMo Soft= ware, Cambridge, MA

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

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0


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



=C2=A0

--


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

=C2=A0

=C2=A0<= /p> 

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

=C2=A0<= /p> 

-- 
Surveillance is pervasive. Go Dark.


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

=C2=A0


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


--047d7b3a911c391d580505d4529a-- From nobody Sun Oct 19 23:00:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0971A6F7E for ; Sun, 19 Oct 2014 23:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9hrG6khIOCG for ; Sun, 19 Oct 2014 23:00:39 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34261A6F9E for ; Sun, 19 Oct 2014 23:00:34 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x13so4590946wgg.30 for ; Sun, 19 Oct 2014 23:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=1a5JCNKTPFC5vRJXpRUJPPoB1RNwrnuVy5rK9jI9p1g=; b=dXObZh6sIvTQh7oMvBhEGn8/2fbu6hCZg0vJHQf8XWtmc8xZY4U3YIZ8nsC8NnaI3F zDkfzO3CY1Na04Oa49HeWX60NiswMJA61xX3SewwieCvz9s3RJoW0GPt5Q5NGjofhXtq rpzxuz1SgLsXPxMoP9dzok9ua+tATc6SdAfltqEVUybw/9WwaBFQWq+DuT+QZRulGFO2 +xWzYqzqfdX7pkLx91yeiG1bo1HRvB/wTso5ZkIueIie3qe9jplc3PIOCu+KCgxRyHIW OVJ4oJJsjJG5AQaBaWFCRIYPT4MqAo5ffb8GMz0u1BjXB0CKEgXfnKRbvZn9XD1XAMmc lGTg== X-Received: by 10.180.73.244 with SMTP id o20mr17715744wiv.9.1413784833087; Sun, 19 Oct 2014 23:00:33 -0700 (PDT) Received: from [100.68.225.94] (227.82-130-185.dynamic.clientes.euskaltel.es. [82.130.185.227]) by mx.google.com with ESMTPSA id h4sm10647001wjb.9.2014.10.19.23.00.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Oct 2014 23:00:32 -0700 (PDT) References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <09B5A70C-2537-412E-9898-E60E72008CBA@gmail.com> X-Mailer: iPhone Mail (11D201) From: Victor Pascual Date: Mon, 20 Oct 2014 08:00:21 +0200 To: Ca By Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Awknzo7sxd1al1Xq5t5HVA_9cP4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 06:00:41 -0000 And that's what the 3GPP is doing for release 12: http://webrtchacks.com/ims= -approach-webrtc/ > On Oct 20, 2014, at 6:24 AM, Ca By wrote: >=20 > My guess is the IMS will change to interop with webrtc in an effort to sta= y relevant. From nobody Mon Oct 20 00:10:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF4C1A6FD1 for ; Mon, 20 Oct 2014 00:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XebugREpLz2t for ; Mon, 20 Oct 2014 00:10:09 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 03CCA1A6FC4 for ; Mon, 20 Oct 2014 00:10:08 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 20 Oct 2014 00:09:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,754,1406617200"; d="scan'208,217";a="592201004" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga001.jf.intel.com with ESMTP; 20 Oct 2014 00:09:19 -0700 Received: from orsmsx116.amr.corp.intel.com (10.22.240.14) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Oct 2014 00:09:19 -0700 Received: from fmsmsx106.amr.corp.intel.com (10.18.124.204) by ORSMSX116.amr.corp.intel.com (10.22.240.14) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Oct 2014 00:09:18 -0700 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.180]) by FMSMSX106.amr.corp.intel.com ([10.18.124.204]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 00:09:18 -0700 From: "Cavigioli, Chris" To: Justin Uberti Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP69ySvH0vdbAWv0eULyOYAeS/S5w4ZQqA//+vamCAAN0qAP//jtwg Date: Mon, 20 Oct 2014 07:09:17 +0000 Message-ID: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.107] Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD2400699DEfmsmsx118amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vbM3V7v7AKs7oUlsoMDyPaHoUnY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 07:10:14 -0000 --_000_E36D1A4AE0B6AA4091F1728D584A6AD2400699DEfmsmsx118amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIG5vdCAyIGRpc2N1c3Npb25zIOKApiBidXQgMiBNVEkgY29kZWNzLg0KR2l2ZW46DQoNCi0g ICAgICAgSW5kdXN0cnkgaXMgcG9sYXJpemVkIGMuIDQwJSBWUDggdnMuIGMuIDQwJSBILjI2NA0K DQotICAgICAgIFVubGlrZWx5IHRoaXMgd2lsbCBjaGFuZ2UNCg0KLSAgICAgICBFdmVyeSBzaW5n bGUgbW9iaWxlIGRldmljZSAoMTAwJSkgb2YgdGhlIGJpbGxpb25zIG91dCB0aGVyZSBydW5uaW5n IGEgbW9iaWxlIE9TIChpT1MsIEFuZHJvaWQsIFdpbmRvd3MsIEJCIE9TLCBldGMpIHdpbGwgYWxy ZWFkeSBzdXBwb3J0IEguMjY0LCBBTVIteHggc2luY2UgdGhvc2UgYXJlIE1USSBmb3IgM0dQUCBh bmQgZm9yIHRoZSBPUw0KVGhlbjoNCg0KLSAgICAgICBXaHkgbm90IHN1cHBvcnQgYm90aDogIFZQ OCwgT3B1cyA9IHdlYjsgSC4yNjQsIEFNUi9BTVItV0IgPSBMVEUNCg0KLSAgICAgICBFdmVyeSBz aW5nbGUgbW9iaWxlIGRldmljZSBhbmQgT1MgYWxyZWFkeSBkZWFscyB3aXRoIEguMjY0K0FNUiBs aWNlbnNpbmcgZm9yIG1hbnkgeWVhcnMuDQoNCi0gICAgICAgQmVpbmcgcm95YWx0eSBmcmVlLCBp bmNyZW1lbnRhbGx5IGFkZGluZyBWUDggYW5kIE9wdXMgc2hvdWxkbuKAmXQgYmUgYSBtYWpvciBh ZGRpdGlvbmFsIGltcGFjdA0KLWNocmlzDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpq dWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiBTdW5kYXksIE9jdG9iZXIgMTksIDIwMTQgMTA6NTIg UE0NClRvOiBDYXZpZ2lvbGksIENocmlzDQpDYzogSGFyYWxkIEFsdmVzdHJhbmQ7IEJlcm5hcmQg QWJvYmE7IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFBsYW4gZm9yIE1U SSB2aWRlbyBjb2RlYz8NCg0KTG9va3MgbGlrZSBzb21lb25lIHdhbnRzIHRvIGhhdmUgbm90IGp1 c3Qgb25lLCBidXQgdHdvIE1USSBjb2RlYyBkaXNjdXNzaW9ucy4uLg0KDQpPbiBTdW4sIE9jdCAx OSwgMjAxNCBhdCA2OjIwIFBNLCBDYXZpZ2lvbGksIENocmlzIDxjaHJpcy5jYXZpZ2lvbGlAaW50 ZWwuY29tPG1haWx0bzpjaHJpcy5jYXZpZ2lvbGlAaW50ZWwuY29tPj4gd3JvdGU6DQpIYXJhbGQg c2FpZDoNCuKAnFdlIG1hZGUgdGhlIG1pc3Rha2Ugb2YgaGF2aW5nIGFuIE1USSBkaXNjdXNzaW9u IHByZXZpb3VzbHkgd2l0aCBub3QgZW5vdWdoIGRldGFpbHMgb24gdGhhdCBzdWJqZWN04oCm4oCd DQoNCldlIGRpZG7igJl0IGhhdmUgcXVhbnRpdGF0aXZlIGRhdGEgZWFybGllciBmb3IgYSBkYXRh LWRyaXZlbiBkZWNpc2lvbi4gIEZ1dHVyZSBXZWIg4oCTIExURSBpbnRlcm9wIGlzIGltcG9ydGFu dC4gIEEgZ3JvdXAgb2YgdXMgaW4gR1NNQSBoYXZlIGJlZW4gbG9va2luZyBhdCBXZWJSVEMgaW50 ZXJvcCB3aXRoIExURSAod2hlcmUgM0dQUCAvIEdTTUEgZGVmaW5lZCBJTVMtYmFzZWQgdm9pY2Uv dmlkZW8vbWVzc2FnaW5nKSwgc3BlY2lmaWNhbGx5IGxvb2tpbmcgYXQgdXNlciBleHBlcmllbmNl IGltcGFjdCBvZiBsYXRlbmN5IGludHJvZHVjZWQgYnkgYWRkZWQgaW4tbmV0d29yayB0cmFuc2Nv ZGluZy4gIEdTTUEgaGFzIGFwcHJvdmVkIHRoZSB3aGl0ZXBhcGVyIGFuZCBpdCBpcyBiZWluZyBw cmVwYXJlZCBmb3IgcHVibGljIGRpc3RyaWJ1dGlvbi4NCg0KV2ViUlRDIOKAkyBMVEUgdHJhbnNj b2RpbmcgaXMgbm93IE1BTkRBVE9SWSBiZWNhdXNlIG9mIOKAnFdlYlJUQyBBdWRpbyBDb2RlYyBh bmQgUHJvY2Vzc2luZyBSZXF1aXJlbWVudHPigJ0uIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTA1LCB3aGVyZSBNVEkgYXVkaW8gY29kZWNzIGluIFdl YlJUQyBhbmQgaW4gTFRFIGFyZSBkaXNzaW1pbGFyLiAgVGh1cywgUkVHQVJETEVTUyBvZiB0aGUg dmlkZW8gY29kZWNzLCB0aGVyZSBpcyBhbHJlYWR5IGEgc2lnbmlmaWNhbnQgZGVncmFkYXRpb24g aW1wb3NlZCBvbiBXZWIg4oCTIExURSBsaW5rcyBpZiBvbmx5IE1USSBjb2RlY3MgYXJlIHVzZWQu ICBUaGUgb25seSBzeXN0ZW1zIHRvIGF2b2lkIHRoaXMgYXJlIHRob3NlIHdoaWNoIGltcGxlbWVu dCBPUFRJT05BTCBhdWRpbyBjb2RlY3MgdG8gYmUgdHJhbnNjb2Rlci1mcmVlIHdpdGggTFRFLiAg VGhlIHNhbWUgY2FuIGFwcGx5IGZvciB2aWRlbyBjb2RlY3MuDQoNClRoZSBHU01BIHdoaXRlcGFw ZXIgcmVmZXJzIHRvOg0KDQoxLiAgICAgUXVhbnRpdGF0aXZlIHZvaWNlLW92ZXItTFRFIChWb0xU RSkgZGVsYXkgbGltaXRzIHdlcmUgYWdyZWVkLXRvIGJ5IDNHUFAgU0E0IGluIEF1Z3VzdCAyMDE0 LiAgVG8gcGFyYXBocmFzZSwgcGVyZm9ybWFuY2Ugb2JqZWN0aXZlcyBmb3IgbWF4aW11bSBWb0xU RSBkZXZpY2UgZGVsYXlzIGluIGVycm9yIGFuZCBqaXR0ZXIgZnJlZSBjb25kaXRpb25zIGFuZCBB TVIgc3BlZWNoIGNvZGVjIG9wZXJhdGlvbiwgdGhlIHN1bSBvZiB0aGUgVUUgZGVsYXlzIGluIHNl bmRpbmcgYW5kIHJlY2VpdmluZyBkaXJlY3Rpb25zIChUUyArIFRSKSBzaG91bGQgYmUg4omkIDE1 MG1zLiBJZiB0aGlzIHBlcmZvcm1hbmNlIG9iamVjdGl2ZSBjYW5ub3QgYmUgbWV0LCB0aGUgc3Vt IG9mIHRoZSBVRSBkZWxheXMgaW4gc2VuZGluZyBhbmQgcmVjZWl2aW5nIGRpcmVjdGlvbnMgKFRT ICsgVFIpIHNoYWxsIGluIGFueSBjYXNlIGJlIOKJpCAxOTBtcy4NCg0KMi4gICAgIE9QVVMg4oCT IEFNUiB0cmFuc2NvZGluZyBhZGRzIGFuIGFkZGl0aW9uYWwgMjExLjUgbXMgaW1wbGVtZW50YXRp b24tYWdub3N0aWMgKFRTICsgVFIpIGRlbGF5LCBpbmNsdWRpbmcgNDAgbXMgZm9yIGppdHRlciBi dWZmZXIgYW5kIDQwIG1zIGZvciBkaXNjb250aW51b3VzIHJlY2VwdGlvbiAoRFJYKS4NCg0KMy4g ICAgIFRvIHB1dCB0aGVzZSBudW1iZXJzIGluIHBlcnNwZWN0aXZlLCBpdCBpcyBpbiBnZW5lcmFs IGRlc2lyYWJsZSB0byBtaW5pbWl6ZSBVRSBkZWxheXMgdG8gZW5zdXJlIGxvdyBlbm91Z2ggZW5k LXRvLWVuZCBkZWxheXMgYW5kIGhlbmNlIGEgZ29vZCBjb252ZXJzYXRpb25hbCBleHBlcmllbmNl LiAgSW5jcmVhc2luZyBkZWxheSBjYXVzZXMgcGVvcGxlIHRvIGRvdWJsZS10YWxrIG1ha2luZyBj b252ZXJzYXRpb25zIGluY3JlYXNpbmdseSBmcnVzdHJhdGluZy4gIEd1aWRhbmNlIHRvIHN0YXkg YmVsb3cgNDAwIG1zIG1heGltdW0gb25lLXdheSBkZWxheSBpcyBmb3VuZCBpbiBJVFUtVCBSZWNv bW1lbmRhdGlvbiBHLjExNCBhbmQgdGhlIGNvbXB1dGF0aW9uYWwgRS1tb2RlbCBpcyBpbiBJVFUt VCBSZWNvbW1lbmRhdGlvbiBHLjEwNy4NCg0KVGhpcyBpcyBhIGNvbXBsZXggdG9waWMgd2l0aCBt YW55IG5ldHdvcmsgZmFjdG9ycyBpbiBwbGF5LiAgTFRFIG9wZXJhdG9ycyBpbiAzR1BQIHNlZWsg VUUgZGVsYXlzIChUUyArIFRSKSBhcm91bmQgMTUwIG1zLiAgQWRkaW5nIE9QVVMg4oCTIEFNUiB0 cmFuc2NvZGluZyBpbiB0aGUgbmV0d29yayBpbXBvc2VzIGFuIGFkZGl0aW9uYWwgMjExLjUgbXMg b24gdG9wIG9mIHRoYXQsIGp1c3QgZm9yIGF1ZGlvLiAgT3B0aW9uYWxseSB1c2luZyBBTVIgaW4g V2ViUlRDLCB0aG9zZSAyMTEuNSBtcyBjYW4gYmUgZWxpbWluYXRlZCwgZGVsaXZlcmluZyBhIHN1 cGVyaW9yIGVuZC11c2VyIGV4cGVyaWVuY2UuDQoNCkNPTkNMVVNJT046ICByZWdhcmRsZXNzIG9m IE1USSBjb2RlYyBjaG9pY2VzIGluIFdlYlJUQywgdG8gcHJvdmlkZSBhIGdvb2QgV2ViUlRDIOKA kyBMVEUgaW50ZXJvcCBleHBlcmllbmNlLCBlbWVyZ2luZyBXZWJSVEMgc3lzdGVtcyBtdXN0IGFj Y29tbW9kYXRlIE1USSBjb2RlY3MgYWxyZWFkeSBkZXBsb3llZCBpbiB0aGUgTFRFIGRvbWFpbiBh bmQgaW4gbW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1zLCBuYW1lbHkgQU1SL0FNUi1XQiBhbmQgSC4y NjQuDQoNClBPU0lUSU9OOiAgVG8gYmUgY2xlYXIsIHNldmVyYWwgSW50ZWwgU29DcyBsYXVuY2hl ZCBhdCBNV0MgdGhpcyB5ZWFyIGZvciBzbWFydHBob25lcyBhbmQgdGFibGV0cyBzdXBwb3J0IGJv dGggVlA4IGFuZCBILjI2NCBoYXJkd2FyZSBlbmNvZGUgYW5kIGRlY29kZSDigJMgc28gSW50ZWwg aXMgY29kZWMtbmV1dHJhbCBpbiB0aGlzIE1USSBkZWJhdGUuICBBZGRpdGlvbmFsbHksIEludGVs IGhhcyBoaWdoLXBlcmZvcm1hbmNlIHNvbHV0aW9ucyBmb3IgdHJhbnNjb2RpbmcuICBIb3dldmVy LCB3ZSB3aXNoIHRvIGluZm9ybSB0aGUgaW5kdXN0cnksIHdpdGggcXVhbnRpdGF0aXZlIGRhdGEs IGFib3V0IGltcGFjdCB0byBlbmQtdXNlciBleHBlcmllbmNlIG9mIG1hbmRhdGluZyBzdWNoIHRy YW5zY29kaW5nIHNvIElFVEYgY2FuIG1ha2UgYSBkYXRhLWRyaXZlbiBkZWNpc2lvbiBvbiB2aWRl byBjb2RlY3MgYXMgd2VsbCBhcyByZWZsZWN0IG9uIHRoZSBpbXBhY3Qgb2YgYWxyZWFkeSBoYXZp bmcgbWFuZGF0ZWQgdHJhbnNjb2Rpbmcgb24gdGhlIGF1ZGlvIHNpZGUuDQoNCkNocmlzIENhdmln aW9saQ0KSW50ZWwgQ29ycCwgU3lzdGVtIEFyY2hpdGVjdHVyZSBhbmQgUGxhbm5pbmcsIFZpZGVv L011bHRpbWVkaWEsIE1vYmlsZSBhbmQgQ29tbXVuaWNhdGlvbnMgR3JvdXAgKE1DRykNCisxICg0 MTUpIDI1NC00NTQ1PHRlbDolMkIxJTIwJTI4NDE1JTI5JTIwMjU0LTQ1NDU+IG1vYmlsZQ0KKzEg KDQwOCkgNjUzLTgzNDg8dGVsOiUyQjElMjAlMjg0MDglMjklMjA2NTMtODM0OD4gZGVzaw0KKzEg KDQwOCkgODg0LTI0MDA8dGVsOiUyQjElMjAlMjg0MDglMjklMjA4ODQtMjQwMD4gZmF4DQpUaGlz IGUtbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiAgQW55IHJldmll dyBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhh bGYgT2YgQmVybmFyZCBBYm9iYQ0KU2VudDogU3VuZGF5LCBPY3RvYmVyIDE5LCAyMDE0IDI6Mjkg UE0NClRvOiBIYXJhbGQgQWx2ZXN0cmFuZA0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRj d2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFBsYW4gZm9yIE1USSB2aWRlbyBj b2RlYz8NCg0KSGFyYWxkIHNhaWQ6DQoNCiJCZXJuYXJkLA0KDQpJIHRoaW5rIHRoaXMgaXMsIHRv IGEgbGFyZ2UgZGVncmVlLCBjb2RlYyBpbmRlcGVuZGVudC4NCg0KV2UgaGF2ZSBkZW1vbnN0cmF0 ZWQgaW50ZXJvcGVyYWJpbGl0eSBvbiBWUDggYmV0d2VlbiBGaXJlZm94IGFuZCBDaHJvbWUsIGFu ZCB1c2FnZSBvZiB2YXJpb3VzIG1lY2hhbmlzbXMgZm9yIGNvbmdlc3Rpb24gY29udHJvbCBhbmQg cmVwYWlyIG9mIHBhY2tldCBsb3NzIGJlaW5nIGFwcGxpZWQgaW4gbGl2ZSBzZXJ2aWNlcy4NClNv IGl0IGNhbid0IGJlIGFsbCBiYWQuLi4uLiINCg0KW0JBXSAgSSBhZ3JlZSB0aGF0IHRoZSBsYWNr IG9mIGludGVyb3BlcmFiaWxpdHkgaXMgbGFyZ2VseSAiY29kZWMgaW5kZXBlbmRlbnQiOiAgIHRo YXQgaXMsIGltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBkaWZmZXJlbnQgbWVjaGFuaXNtcyBmb3Ig Y29uZ2VzdGlvbiBjb250cm9sLCByZXBhaXIsIGV0Yy4gd2lsbCBleGhpYml0IGludGVyb3BlcmFi aWxpdHkgcHJvYmxlbXMsIHJlZ2FyZGxlc3Mgb2YgdGhlIGNvZGVjIGNob3Nlbi4gICBUaGUgcmVh bCB0ZXN0IGZvciBSVENXRUIgd2lsbCBiZSB0byBtb3ZlIGJleW9uZCAiaW50ZXJvcGVyYWJpbGl0 eSBvZiBpbXBsZW1lbnRhdGlvbnMgc2hhcmluZyBzb3VyY2UgY29kZSIgIHRvICJpbnRlcm9wZXJh YmlsaXR5IG9mIGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucywgYmFzZWQgb24gb3BlbiBzdGFu ZGFyZHMiLg0KDQpPbiBTdW4sIE9jdCAxOSwgMjAxNCBhdCAxOjM4IFBNLCBIYXJhbGQgQWx2ZXN0 cmFuZCA8aGFyYWxkQGFsdmVzdHJhbmQubm88bWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPj4g d3JvdGU6DQpPbiAxMC8xOS8yMDE0IDA1OjQzIFBNLCBCZXJuYXJkIEFib2JhIHdyb3RlOg0KIkFu ZCBpdHMgb25lIG9mIHRoZSBpc3N1ZXMgaG9sZGluZyB1cCB3aWRlciBhZG9wdGlvbiBvZiB0aGUg dGVjaG5vbG9neSINCg0KW0JBXSBTcGVjaWZ5aW5nIGFuIE1USSBlbmNvZGVyL2RlY29kZXIgaXMg bm90IHN1ZmZpY2llbnQgZm9yIGludGVyb3BlcmFiaWxpdHkuICBJdCBpcyBhbHNvIG5lY2Vzc2Fy eSB0byBzcGVjaWZ5IHRoZSB0cmFuc3BvcnQgaW4gZW5vdWdoIGRldGFpbCB0byBhbGxvdyBpbmRl cGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBpbnRlcm9wZXJhdGUgd2VsbCBlbm91Z2ggdG8g YmUgdXNhYmxlIGluIGEgd2lkZSB2YXJpZXR5IG9mIHNjZW5hcmlvcywgaW5jbHVkaW5nIHdpcmVs ZXNzIG5ldHdvcmtzIHdoZXJlIGxvc3MgaXMgY29tbW9ubHkgZXhwZXJpZW5jZWQuDQoNCkJlcm5h cmQsDQoNCkkgdGhpbmsgdGhpcyBpcywgdG8gYSBsYXJnZSBkZWdyZWUsIGNvZGVjIGluZGVwZW5k ZW50Lg0KDQpXZSBoYXZlIGRlbW9uc3RyYXRlZCBpbnRlcm9wZXJhYmlsaXR5IG9uIFZQOCBiZXR3 ZWVuIEZpcmVmb3ggYW5kIENocm9tZSwgYW5kIHVzYWdlIG9mIHZhcmlvdXMgbWVjaGFuaXNtcyBm b3IgY29uZ2VzdGlvbiBjb250cm9sIGFuZCByZXBhaXIgb2YgcGFja2V0IGxvc3MgYmVpbmcgYXBw bGllZCBpbiBsaXZlIHNlcnZpY2VzLg0KDQpTbyBpdCBjYW4ndCBiZSBhbGwgYmFkLi4uLi4NCg0K DQpXZSBtYWRlIHRoZSBtaXN0YWtlIG9mIGhhdmluZyBhbiBNVEkgZGlzY3Vzc2lvbiBwcmV2aW91 c2x5IHdpdGggbm90IGVub3VnaCBkZXRhaWxzIG9uIHRoYXQgc3ViamVjdCwgcGFydGljdWxhcmx5 IHdpdGggcmVzcGVjdCB0byBILjI2NC4gZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8gc2VjdGlvbnMg NC4yIC0gNC40IHJlbWFpbiBza2V0Y2h5IGF0IGJlc3QuDQoNClNvIGlmIHdlIGFyZSB0byBoYXZl IHRoZSBkaXNjdXNzaW9uIGFnYWluLCBpdCBzaG91bGQgb2NjdXIgaW4gdGhlIGNvbnRleHQgb2Yg ZGV0YWlsZWQgc3BlY2lmaWNhdGlvbnMgYW5kIGludGVyb3BlcmFiaWxpdHkgcmVwb3J0cy4NCg0K DQoNCg0KDQpPbiBTdW4sIE9jdCAxOSwgMjAxNCBhdCA4OjE0IEFNLCBKb25hdGhhbiBSb3NlbmJl cmcgPGpkcm9zZW5AamRyb3Nlbi5uZXQ8bWFpbHRvOmpkcm9zZW5AamRyb3Nlbi5uZXQ+PiB3cm90 ZToNCkknbSBpbiBmYXZvciBvZiB0YWtpbmcgYW5vdGhlciBydW4gYXQgdGhpcy4NCg0KVGhlIHdv cmtpbmcgZ3JvdXAgaGFzIHJlcGVhdGVkbHkgc2FpZCB0aGF0IGFuIE1USSBjb2RlYyBpcyBzb21l dGhpbmcgd2UgbmVlZCB0byBwcm9kdWNlLiBBbmQgaXRzIG9uZSBvZiB0aGUgaXNzdWVzIGhvbGRp bmcgdXAgd2lkZXIgYWRvcHRpb24gb2YgdGhlIHRlY2hub2xvZ3kgKG5vdCB0aGUgb25seSBvbmUg Zm9yIHN1cmUpLg0KDQpBbmQgdGhpbmdzIGhhdmUgY2hhbmdlZCBzaW5jZSB0aGUgbGFzdCBtZWV0 aW5nLCBhIHllYXIgYWdvIG5vdyAoTm92ZW1iZXIgaW4gVmFuY291dmVyKS4gQ2lzY28ncyBvcGVu MjY0IHBsdWdpbiBzaGlwcGVkIGFuZCBub3cganVzdCByZWNlbnRseSBpcyBpbnRlZ3JhdGVkIGlu dG8gRmlyZWZveC4gaU9TOCBzaGlwcGVkIHdpdGggQVBJcyBmb3IgSDI2NC4gVGhlcmUgYXJlIG90 aGVyIHRoaW5ncyB3b3J0aCBub3RpbmcuIFdpbGwgdGhpcyBjaGFuZ2UgdGhlIG1pbmRzIG9mIGV2 ZXJ5b25lPyBTdXJlbHkgbm90LiBXaWxsIGl0IHN3YXkgZW5vdWdoIGZvciB1cyB0byBhY2hpZXZl IHJvdWdoIGNvbnNlbnN1cz8gTWF5YmUuIElNSE8gLSB3b3J0aCBmaW5kaW5nIG91dC4NCg0KT24g U2F0LCBPY3QgMTgsIDIwMTQgYXQgNTowOCBQTSwgQWxleGFuZHJlIEdPVUFJTExBUkQgPGFnb3Vh aWxsYXJkQGdtYWlsLmNvbTxtYWlsdG86YWdvdWFpbGxhcmRAZ21haWwuY29tPj4gd3JvdGU6DQor MSB0byBub3QgaGF2aW5nIE1USSBjb2RlYyBkaXNjdXNzaW9uIHVubGVzcyBzb21lIHByb2dyZXNz IGhhcyBiZWVuIG1hZGUgb24gVlA4IGF0IE1QRUcuIEFueSBuZXdzIG9uIHRoYXQ/IEknbSBzaGFy aW5nIGhhcmFsZCdzICBmZWVsaW5nIHRoYXQgdGhlcmUgd2FzIG5vIGNoYW5nZSBvbiB0aGUgbWVt YmVycyBwb3NpdGlvbi4NCg0KT24gRnJpLCBPY3QgMTcsIDIwMTQgYXQgOToyMiBQTSwgSGFyYWxk IEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFu ZC5ubz4+IHdyb3RlOg0KT24gMTAvMTcvMjAxNCAxMjowMiBBTSwgQmVybmFyZCBBYm9iYSB3cm90 ZToNCk9uZSB0aGluZyB3ZSBjb3VsZCBkbyBpbnN0ZWFkIG9mIHdhc3RpbmcgdGltZSBvbiBNVEkg aXMgdG8gYWN0dWFsbHkgbWFrZSBwcm9ncmVzcyBvbiBTZWN0aW9ucyA0LjIgLSA0LjQgb2YgZHJh ZnQtSUVURi1SVENXRUItdmlkZW8sIHNvIHdlIGNvdWxkIGFjdHVhbGx5IGludGVyb3BlcmF0ZSBy ZWdhcmRsZXNzIG9mIHRoZSBjb2RlYy4NCg0KVGhlIGJpZyBhcmd1bWVudCBmb3IgYW4gTVRJIGlz IGFjdHVhbGx5IHRoZSBvbmUgc3RhdGVkIGluIC1vdmVydmlldzogSXQgZ3VhcmRzIGFnYWluc3Qg aW50ZXJvcGVyYWJpbGl0eSBmYWlsdXJlLg0KDQpJIHdvdWxkIGxpa2UgdG8gaGF2ZSBhbiBlY29z eXN0ZW0gd2hlcmUgb25lIGNhbiBmaWVsZCBhIGJveCwgY29ubmVjdCBpdCB0byBldmVyeXRoaW5n IGVsc2UsIGFuZCBydW4gd2VsbCBmb3IgKnNvbWUqIGxldmVsIG9mICJ3ZWxsIiAtIGFuZCBJIHdv dWxkIHByZWZlciB0aGF0IGVjb3N5c3RlbSB0byBiZSBvbmUgd2hlcmUgaXQncyBwb3NzaWJsZSB0 byBmaWVsZCB0aGUgYm94IHdpdGhvdXQgbWFraW5nIHByaW9yIGFycmFuZ2VtZW50cyB3aXRoIGFu eW9uZSBhYm91dCBsaWNlbnNlcy4NCg0KVGhpcyBhcmd1bWVudCBoYXNuJ3QgY2hhbmdlZCBvbmUg d2hpdCBzaW5jZSBsYXN0IHRpbWUgd2UgZGlzY3Vzc2VkIGl0LiBBbmQgSSBkb24ndCBzZWUgbXVj aCBtb3ZlbWVudCBvbiB0aGUgc3BlY2lmaWNzIG9mIHRoZSBwcm9wb3NhbHMgZWl0aGVyLg0KDQpX ZSdsbCBoYXZlIHRvIGludGVyb3BlcmF0ZSB3ZWxsIHdpdGggdGhlIGNvZGVjcyB3ZSBmaWVsZC4g U28gdXNpbmcgc29tZSB0aW1lIHRvIGRpc2N1c3MgZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8gc2Vl bXMgdG8gbWFrZSBzZW5zZS4gKEFuZCA0LjEgaXNuJ3QgZmluaXNoZWQgZWl0aGVyLiBUaGVyZSdz IG9uZSBzZW50ZW5jZSB0aGF0IG5lZWRzIHRvIGJlIHJlbW92ZWQuKQ0KDQpJIHdvdWxkbid0IHNh eSBJJ2QgYmUgaGFwcHkgdG8gbm90IGRpc2N1c3MgdGhpcyBpbiBIb25vbHVsdS4gQnV0IEknZCBw cmVmZXIgdG8gcmUtZGlzY3VzcyBiYXNlZCBvbiB0aGUga25vd2xlZGdlIHRoYXQgc29tZSBzaWdu aWZpY2FudCBwbGF5ZXJzIGhhdmUgYWN0dWFsbHkgY2hhbmdlZCB0aGVpciBtaW5kcy4NCg0KQXQg dGhlIG1vbWVudCwgSSBkb24ndCBzZWUgc2lnbnMgdGhhdCBhbnkgb2YgdGhlIHBvbGwgcmVzcG9u ZGVudHMgaGF2ZSBzYWlkICJJIGhhdmUgY2hhbmdlZCBteSBtaW5kIi4NCg0KSGFyYWxkDQoNCg0K T24gT2N0IDE2LCAyMDE0LCBhdCAyOjI4IFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21z b25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCk9u IDE2IE9jdG9iZXIgMjAxNCAxNDoxNywgTWF0dGhldyBLYXVmbWFuIDxtYXR0aGV3QG1hdHRoZXcu YXQ8bWFpbHRvOm1hdHRoZXdAbWF0dGhldy5hdD4+IHdyb3RlOg0KQW5kIHRoYXQncyBiZWNhdXNl IHNvbWV0aGluZyBzdWJzdGFudGl2ZSBoYXMgY2hhbmdlZCwgb3Igc2ltcGx5IGJlY2F1c2UNCndh c3RpbmcgdGhlIFdHIHRpbWUgb24gdGhpcyBhZ2FpbiBpcyBtb3JlIGVudGVydGFpbmluZyB0aGFu IGFjdHVhbGx5DQpmaW5pc2hpbmcgYSBzcGVjaWZpY2F0aW9uIHRoYXQgY2FuIGJlIGluZGVwZW5k ZW50bHkgaW1wbGVtZW50ZWQgYnkgYWxsDQpicm93c2VyIHZlbmRvcnM/IChBIHNwZWNpZmljYXRp b24gdGhhdCB3ZSBhcmUgbm93aGVyZSBuZWFyIGhhdmluZywgYXMgZmFyIGFzDQpJIGNhbiB0ZWxs KQ0KUGVyc29uYWxseSwgSSd2ZSBmb3VuZCB0aGUgcmVwcmlldmUgZnJvbSB0aGlzIGZpZ2h0IHJl ZnJlc2hpbmcuICBBbmQNCml0IHdvdWxkIGFwcGVhciB0aGF0IHdlJ3ZlIG1hZGUgc29tZSByZWFs IHByb2dyZXNzIGFzIGEgcmVzdWx0LiAgSSdkDQpzdWdnZXN0IHRoYXQgaWYgd2UgZG9uJ3QgaGF2 ZSBuZXcgaW5mb3JtYXRpb24sIHdlIGNvbnRpbnVlIHRvIHNwZW5kDQpvdXIgdGltZSBwcm9kdWN0 aXZlbHkuICBJZiB3ZSBjYW4ndCBmaW5kIHRvcGljcyB0byBvY2N1cHkgb3VyIG1lZXRpbmcNCmFn ZW5kYSB0aW1lLCB0aGVuIG1heWJlIHdlIGNhbiBmcmVlIGFuIGFnZW5kYSBzbG90Lg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxp bmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxt YWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWINCg0KDQoNCi0tDQpBbGV4LiBHb3VhaWxsYXJkLCBQaEQsIFBoRCwgTUJBDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNUTyAtIFRlbWFzeXMgQ29tbXVuaWNhdGlvbnMs IFMncG9yZSAvIE1vdW50YWluIFZpZXcNClByZXNpZGVudCAtIENvU01vIFNvZnR3YXJlLCBDYW1i cmlkZ2UsIE1BDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnNnLmxpbmtlZGluLmNvbS9h Z291YWlsbGFyZDxodHRwOi8vc2cubGlua2VkaW4uY29tL2Fnb3VhaWxsYXJkPg0K4oCiDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFp bGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQotLQ0KSm9uYXRo YW4gUm9zZW5iZXJnLCBQaC5ELg0KamRyb3NlbkBqZHJvc2VuLm5ldDxtYWlsdG86amRyb3NlbkBq ZHJvc2VuLm5ldD4NCmh0dHA6Ly93d3cuamRyb3Nlbi5uZXQNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCg0KcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KLS0NCg0KU3VydmVpbGxhbmNlIGlzIHBlcnZhc2l2 ZS4gR28gRGFyay4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRj d2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_E36D1A4AE0B6AA4091F1728D584A6AD2400699DEfmsmsx118amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTppbmhl cml0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5v c2UtMToyIDExIDYgOSA0IDUgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo1Mzk5NzkwNzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjkzNzQyODM4MCAtOTczNzIyOTcyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OlZlcmRhbmE7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Tm8sIG5vdCAyIGRpc2N1c3Npb25zIOKApiBidXQgMiBNVEkgY29kZWNzLiZuYnNwOw0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HaXZlbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4t PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluZHVzdHJ5 IGlzIHBvbGFyaXplZCBjLiA0MCUgVlA4IHZzLiBjLiA0MCUgSC4yNjQNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VW5saWtlbHkgdGhpcyB3aWxsIGNoYW5nZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXZlcnkgc2luZ2xl IG1vYmlsZSBkZXZpY2UgKDEwMCUpIG9mIHRoZSBiaWxsaW9ucyBvdXQgdGhlcmUgcnVubmluZyBh IG1vYmlsZSBPUyAoaU9TLCBBbmRyb2lkLCBXaW5kb3dzLCBCQiBPUywgZXRjKSB3aWxsIGFscmVh ZHkgc3VwcG9ydCBILjI2NCwgQU1SLXh4DQogc2luY2UgdGhvc2UgYXJlIE1USSBmb3IgM0dQUCBh bmQgZm9yIHRoZSBPUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlbjo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPldoeSBub3Qgc3VwcG9ydCBib3RoOiZuYnNwOyBWUDgsIE9wdXMgPSB3ZWI7IEguMjY0 LCBBTVIvQU1SLVdCID0gTFRFPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVyeSBzaW5nbGUgbW9iaWxlIGRl dmljZSBhbmQgT1MgYWxyZWFkeSBkZWFscyB3aXRoIEguMjY0JiM0MztBTVIgbGljZW5zaW5nIGZv ciBtYW55IHllYXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVpbmcgcm95YWx0eSBmcmVlLCBpbmNyZW1l bnRhbGx5IGFkZGluZyBWUDggYW5kIE9wdXMgc2hvdWxkbuKAmXQgYmUgYSBtYWpvciBhZGRpdGlv bmFsIGltcGFjdA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tY2hyaXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anVi ZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgT2N0b2JlciAxOSwg MjAxNCAxMDo1MiBQTTxicj4NCjxiPlRvOjwvYj4gQ2F2aWdpb2xpLCBDaHJpczxicj4NCjxiPkNj OjwvYj4gSGFyYWxkIEFsdmVzdHJhbmQ7IEJlcm5hcmQgQWJvYmE7IHJ0Y3dlYkBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUGxhbiBmb3IgTVRJIHZpZGVvIGNvZGVj PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tzIGxpa2Ugc29tZW9u ZSB3YW50cyB0byBoYXZlIG5vdCBqdXN0IG9uZSwgYnV0IHR3byBNVEkgY29kZWMgZGlzY3Vzc2lv bnMuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1 biwgT2N0IDE5LCAyMDE0IGF0IDY6MjAgUE0sIENhdmlnaW9saSwgQ2hyaXMgJmx0OzxhIGhyZWY9 Im1haWx0bzpjaHJpcy5jYXZpZ2lvbGlAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMu Y2F2aWdpb2xpQGludGVsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGFyYWxkIHNhaWQ6Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPuKAnFdlIG1hZGUgdGhlIG1pc3Rha2Ugb2YgaGF2aW5n IGFuIE1USSBkaXNjdXNzaW9uIHByZXZpb3VzbHkgd2l0aCBub3QgZW5vdWdoIGRldGFpbHMgb24g dGhhdCBzdWJqZWN04oCm4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGRpZG7igJl0IGhhdmUgcXVhbnRpdGF0aXZlIGRhdGEg ZWFybGllciBmb3IgYSBkYXRhLWRyaXZlbiBkZWNpc2lvbi4mbmJzcDsgRnV0dXJlIFdlYiDigJMg TFRFIGludGVyb3AgaXMgaW1wb3J0YW50LiZuYnNwOw0KIEEgZ3JvdXAgb2YgdXMgaW4gR1NNQSBo YXZlIGJlZW4gbG9va2luZyBhdCBXZWJSVEMgaW50ZXJvcCB3aXRoIExURSAod2hlcmUgM0dQUCAv IEdTTUEgZGVmaW5lZCBJTVMtYmFzZWQgdm9pY2UvdmlkZW8vbWVzc2FnaW5nKSwgc3BlY2lmaWNh bGx5IGxvb2tpbmcgYXQgdXNlciBleHBlcmllbmNlIGltcGFjdCBvZiBsYXRlbmN5IGludHJvZHVj ZWQgYnkgYWRkZWQgaW4tbmV0d29yayB0cmFuc2NvZGluZy4mbmJzcDsgR1NNQSBoYXMgYXBwcm92 ZWQgdGhlIHdoaXRlcGFwZXINCiBhbmQgaXQgaXMgYmVpbmcgcHJlcGFyZWQgZm9yIHB1YmxpYyBk aXN0cmlidXRpb24uJm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2ViUlRDIOKAkyBMVEUgdHJhbnNjb2Rpbmcg aXMgbm93IE1BTkRBVE9SWSBiZWNhdXNlIG9mIOKAnFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJv Y2Vzc2luZyBSZXF1aXJlbWVudHPigJ0uDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTA1PC9hPiwgd2hlcmUg TVRJIGF1ZGlvIGNvZGVjcyBpbiBXZWJSVEMgYW5kIGluIExURSBhcmUgZGlzc2ltaWxhci4mbmJz cDsgVGh1cywgUkVHQVJETEVTUyBvZiB0aGUgdmlkZW8gY29kZWNzLCB0aGVyZSBpcyBhbHJlYWR5 IGENCiBzaWduaWZpY2FudCBkZWdyYWRhdGlvbiBpbXBvc2VkIG9uIFdlYiDigJMgTFRFIGxpbmtz IGlmIG9ubHkgTVRJIGNvZGVjcyBhcmUgdXNlZC4mbmJzcDsgVGhlIG9ubHkgc3lzdGVtcyB0byBh dm9pZCB0aGlzIGFyZSB0aG9zZSB3aGljaCBpbXBsZW1lbnQgT1BUSU9OQUwgYXVkaW8gY29kZWNz IHRvIGJlIHRyYW5zY29kZXItZnJlZSB3aXRoIExURS4mbmJzcDsgVGhlIHNhbWUgY2FuIGFwcGx5 IGZvciB2aWRlbyBjb2RlY3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgR1NNQSB3aGl0ZXBhcGVyIHJlZmVycyB0 bzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5RdWFudGl0YXRpdmUgdm9pY2Utb3Zlci1MVEUgKFZv TFRFKSBkZWxheSBsaW1pdHMgd2VyZSBhZ3JlZWQtdG8gYnkgM0dQUCBTQTQgaW4gQXVndXN0IDIw MTQuJm5ic3A7IFRvIHBhcmFwaHJhc2UsIHBlcmZvcm1hbmNlIG9iamVjdGl2ZXMgZm9yIG1heGlt dW0gVm9MVEUgZGV2aWNlIGRlbGF5cyBpbiBlcnJvcg0KIGFuZCBqaXR0ZXIgZnJlZSBjb25kaXRp b25zIGFuZCBBTVIgc3BlZWNoIGNvZGVjIG9wZXJhdGlvbiwgdGhlIHN1bSBvZiB0aGUgVUUgZGVs YXlzIGluIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBkaXJlY3Rpb25zIChUPHN1Yj5TPC9zdWI+ICYj NDM7IFQ8c3ViPlI8L3N1Yj4pIHNob3VsZCBiZSDiiaQgMTUwbXMuIElmIHRoaXMgcGVyZm9ybWFu Y2Ugb2JqZWN0aXZlIGNhbm5vdCBiZSBtZXQsIHRoZSBzdW0gb2YgdGhlIFVFIGRlbGF5cyBpbiBz ZW5kaW5nIGFuZA0KIHJlY2VpdmluZyBkaXJlY3Rpb25zIChUPHN1Yj5TPC9zdWI+ICYjNDM7IFQ8 c3ViPlI8L3N1Yj4pIHNoYWxsIGluIGFueSBjYXNlIGJlIOKJpCAxOTBtcy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5PUFVTIOKAkyBBTVIgdHJhbnNjb2RpbmcgYWRkcyBhbiBhZGRpdGlvbmFsIDIx MS41IG1zIGltcGxlbWVudGF0aW9uLWFnbm9zdGljIChUPHN1Yj5TPC9zdWI+ICYjNDM7IFQ8c3Vi PlI8L3N1Yj4pIGRlbGF5LCBpbmNsdWRpbmcgNDAgbXMgZm9yIGppdHRlciBidWZmZXIgYW5kIDQw IG1zIGZvciBkaXNjb250aW51b3VzDQogcmVjZXB0aW9uIChEUlgpLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+My48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRvIHB1dCB0aGVzZSBudW1iZXJzIGluIHBlcnNwZWN0aXZlLCBpdCBpcyBpbiBnZW5l cmFsIGRlc2lyYWJsZSB0byBtaW5pbWl6ZSBVRSBkZWxheXMgdG8gZW5zdXJlIGxvdyBlbm91Z2gg ZW5kLXRvLWVuZCBkZWxheXMgYW5kIGhlbmNlIGEgZ29vZCBjb252ZXJzYXRpb25hbCBleHBlcmll bmNlLiZuYnNwOyBJbmNyZWFzaW5nDQogZGVsYXkgY2F1c2VzIHBlb3BsZSB0byBkb3VibGUtdGFs ayBtYWtpbmcgY29udmVyc2F0aW9ucyBpbmNyZWFzaW5nbHkgZnJ1c3RyYXRpbmcuJm5ic3A7IEd1 aWRhbmNlIHRvIHN0YXkgYmVsb3cgNDAwIG1zIG1heGltdW0gb25lLXdheSBkZWxheSBpcyBmb3Vu ZCBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjExNCBhbmQgdGhlIGNvbXB1dGF0aW9uYWwgRS1t b2RlbCBpcyBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjEwNy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMg YSBjb21wbGV4IHRvcGljIHdpdGggbWFueSBuZXR3b3JrIGZhY3RvcnMgaW4gcGxheS4mbmJzcDsg TFRFIG9wZXJhdG9ycyBpbiAzR1BQIHNlZWsgVUUgZGVsYXlzIChUPHN1Yj5TPC9zdWI+DQogJiM0 MzsgVDxzdWI+Ujwvc3ViPikgYXJvdW5kIDE1MCBtcy4mbmJzcDsgQWRkaW5nIE9QVVMg4oCTIEFN UiB0cmFuc2NvZGluZyBpbiB0aGUgbmV0d29yayBpbXBvc2VzIGFuIGFkZGl0aW9uYWwgMjExLjUg bXMgb24gdG9wIG9mIHRoYXQsIGp1c3QgZm9yIGF1ZGlvLiZuYnNwOyBPcHRpb25hbGx5IHVzaW5n IEFNUiBpbiBXZWJSVEMsIHRob3NlIDIxMS41IG1zIGNhbiBiZSBlbGltaW5hdGVkLCBkZWxpdmVy aW5nIGEgc3VwZXJpb3IgZW5kLXVzZXIgZXhwZXJpZW5jZS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q09O Q0xVU0lPTjogJm5ic3A7cmVnYXJkbGVzcyBvZiBNVEkgY29kZWMgY2hvaWNlcyBpbiBXZWJSVEMs IHRvIHByb3ZpZGUgYSBnb29kIFdlYlJUQyDigJMgTFRFIGludGVyb3AgZXhwZXJpZW5jZSwNCiBl bWVyZ2luZyBXZWJSVEMgc3lzdGVtcyBtdXN0IGFjY29tbW9kYXRlIE1USSBjb2RlY3MgYWxyZWFk eSBkZXBsb3llZCBpbiB0aGUgTFRFIGRvbWFpbiBhbmQgaW4gbW9iaWxlIG9wZXJhdGluZyBzeXN0 ZW1zLCBuYW1lbHkgQU1SL0FNUi1XQiBhbmQgSC4yNjQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QT1NJVElPTjombmJz cDsgVG8gYmUgY2xlYXIsIHNldmVyYWwgSW50ZWwgU29DcyBsYXVuY2hlZCBhdCBNV0MgdGhpcyB5 ZWFyIGZvciBzbWFydHBob25lcyBhbmQgdGFibGV0cyBzdXBwb3J0DQogYm90aCBWUDggYW5kIEgu MjY0IGhhcmR3YXJlIGVuY29kZSBhbmQgZGVjb2RlIOKAkyBzbyBJbnRlbCBpcyBjb2RlYy1uZXV0 cmFsIGluIHRoaXMgTVRJIGRlYmF0ZS4mbmJzcDsgQWRkaXRpb25hbGx5LCBJbnRlbCBoYXMgaGln aC1wZXJmb3JtYW5jZSBzb2x1dGlvbnMgZm9yIHRyYW5zY29kaW5nLiZuYnNwOyBIb3dldmVyLCB3 ZSB3aXNoIHRvIGluZm9ybSB0aGUgaW5kdXN0cnksIHdpdGggcXVhbnRpdGF0aXZlIGRhdGEsIGFi b3V0IGltcGFjdCB0byBlbmQtdXNlciBleHBlcmllbmNlDQogb2YgbWFuZGF0aW5nIHN1Y2ggdHJh bnNjb2Rpbmcgc28gSUVURiBjYW4gbWFrZSBhIGRhdGEtZHJpdmVuIGRlY2lzaW9uIG9uIHZpZGVv IGNvZGVjcyBhcyB3ZWxsIGFzIHJlZmxlY3Qgb24gdGhlIGltcGFjdCBvZiBhbHJlYWR5IGhhdmlu ZyBtYW5kYXRlZCB0cmFuc2NvZGluZyBvbiB0aGUgYXVkaW8gc2lkZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXMgQ2F2aWdpb2xpPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JbnRlbCBDb3JwLA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMDcwQzAiPlN5c3RlbSBBcmNoaXRlY3R1cmUgYW5kIFBsYW5uaW5nPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiwgVmlkZW8vTXVsdGltZWRp YSwgTW9iaWxlIGFuZCBDb21tdW5pY2F0aW9ucyBHcm91cCAoTUNHKTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0idGVsOiUyQjElMjAlMjg0MTUlMjklMjAyNTQtNDU0NSIg dGFyZ2V0PSJfYmxhbmsiPiYjNDM7MSAoNDE1KSAyNTQtNDU0NTwvYT4gbW9iaWxlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJ0ZWw6JTJCMSUyMCUyODQwOCUyOSUyMDY1 My04MzQ4IiB0YXJnZXQ9Il9ibGFuayI+JiM0MzsxICg0MDgpIDY1My04MzQ4PC9hPiBkZXNrPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJ0ZWw6JTJCMSUyMCUyODQwOCUy OSUyMDg4NC0yNDAwIiB0YXJnZXQ9Il9ibGFuayI+JiM0MzsxICg0MDgpIDg4NC0yNDAwPC9hPiBm YXg8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmdyYXkiPlRoaXMgZS1tYWlsIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQocykuJm5ic3A7DQogQW55IHJldmlldyBvciBkaXN0cmlidXRp b24gYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBh bGwgY29waWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBy dGN3ZWIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5ydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkJlcm5hcmQgQWJvYmE8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBPY3RvYmVyIDE5 LCAyMDE0IDI6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IEhhcmFsZCBBbHZlc3RyYW5kPGJyPg0KPGI+ Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUGxh biBmb3IgTVRJIHZpZGVvIGNvZGVjPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5IYXJhbGQgc2FpZDombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90OzxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkJlcm5hcmQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkkgdGhpbmsgdGhpcyBp cywgdG8gYSBsYXJnZSBkZWdyZWUsIGNvZGVjIGluZGVwZW5kZW50Ljxicj4NCjxicj4NCldlIGhh dmUgZGVtb25zdHJhdGVkIGludGVyb3BlcmFiaWxpdHkgb24gVlA4IGJldHdlZW4gRmlyZWZveCBh bmQgQ2hyb21lLCBhbmQgdXNhZ2Ugb2YgdmFyaW91cyBtZWNoYW5pc21zIGZvciBjb25nZXN0aW9u IGNvbnRyb2wgYW5kIHJlcGFpciBvZiBwYWNrZXQgbG9zcyBiZWluZyBhcHBsaWVkIGluIGxpdmUg c2VydmljZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U28gaXQgY2FuJ3QgYmUgYWxsIGJhZC4u Li4uPC9zcGFuPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+W0JBXSAmbmJzcDtJIGFncmVlIHRoYXQgdGhlIGxhY2sgb2YgaW50 ZXJvcGVyYWJpbGl0eSBpcyBsYXJnZWx5ICZxdW90O2NvZGVjIGluZGVwZW5kZW50JnF1b3Q7OiAm bmJzcDsgdGhhdCBpcywgaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGRpZmZlcmVudCBtZWNoYW5p c21zIGZvciBjb25nZXN0aW9uIGNvbnRyb2wsIHJlcGFpciwgZXRjLiB3aWxsDQogZXhoaWJpdCBp bnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLCByZWdhcmRsZXNzIG9mIHRoZSBjb2RlYyBjaG9zZW4u ICZuYnNwOyBUaGUgcmVhbCB0ZXN0IGZvciBSVENXRUIgd2lsbCBiZSB0byBtb3ZlIGJleW9uZCAm cXVvdDtpbnRlcm9wZXJhYmlsaXR5IG9mIGltcGxlbWVudGF0aW9ucyBzaGFyaW5nIHNvdXJjZSBj b2RlJnF1b3Q7ICZuYnNwO3RvICZxdW90O2ludGVyb3BlcmFiaWxpdHkgb2YgaW5kZXBlbmRlbnQg aW1wbGVtZW50YXRpb25zLCBiYXNlZCBvbiBvcGVuIHN0YW5kYXJkcyZxdW90Oy4gJm5ic3A7Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW4sIE9jdCAxOSwgMjAxNCBh dCAxOjM4IFBNLCBIYXJhbGQgQWx2ZXN0cmFuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhcmFsZEBh bHZlc3RyYW5kLm5vIiB0YXJnZXQ9Il9ibGFuayI+aGFyYWxkQGFsdmVzdHJhbmQubm88L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5PbiAxMC8xOS8yMDE0IDA1OjQzIFBNLCBCZXJuYXJkIEFib2JhIHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O0Fu ZCBpdHMgb25lIG9mIHRoZSBpc3N1ZXMgaG9sZGluZyB1cCB3aWRlciBhZG9wdGlvbiBvZiB0aGUg dGVjaG5vbG9neSZxdW90Ow0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+W0JBXSBTcGVjaWZ5aW5nIGFuIE1USSBlbmNvZGVyL2RlY29kZXIgaXMgbm90 IHN1ZmZpY2llbnQgZm9yIGludGVyb3BlcmFiaWxpdHkuJm5ic3A7IEl0IGlzIGFsc28gbmVjZXNz YXJ5IHRvIHNwZWNpZnkgdGhlIHRyYW5zcG9ydCBpbiBlbm91Z2ggZGV0YWlsIHRvIGFsbG93IGlu ZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucw0KIHRoYXQgaW50ZXJvcGVyYXRlIHdlbGwgZW5vdWdo IHRvIGJlIHVzYWJsZSBpbiBhIHdpZGUgdmFyaWV0eSBvZiBzY2VuYXJpb3MsIGluY2x1ZGluZyB3 aXJlbGVzcyBuZXR3b3JrcyB3aGVyZSBsb3NzIGlzIGNvbW1vbmx5IGV4cGVyaWVuY2VkLiZuYnNw Ow0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQpCZXJuYXJkLDxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBp cywgdG8gYSBsYXJnZSBkZWdyZWUsIGNvZGVjIGluZGVwZW5kZW50Ljxicj4NCjxicj4NCldlIGhh dmUgZGVtb25zdHJhdGVkIGludGVyb3BlcmFiaWxpdHkgb24gVlA4IGJldHdlZW4gRmlyZWZveCBh bmQgQ2hyb21lLCBhbmQgdXNhZ2Ugb2YgdmFyaW91cyBtZWNoYW5pc21zIGZvciBjb25nZXN0aW9u IGNvbnRyb2wgYW5kIHJlcGFpciBvZiBwYWNrZXQgbG9zcyBiZWluZyBhcHBsaWVkIGluIGxpdmUg c2VydmljZXMuPGJyPg0KPGJyPg0KU28gaXQgY2FuJ3QgYmUgYWxsIGJhZC4uLi4uPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIG1hZGUgdGhl IG1pc3Rha2Ugb2YgaGF2aW5nIGFuIE1USSBkaXNjdXNzaW9uIHByZXZpb3VzbHkgd2l0aCBub3Qg ZW5vdWdoIGRldGFpbHMgb24gdGhhdCBzdWJqZWN0LCBwYXJ0aWN1bGFybHkgd2l0aCByZXNwZWN0 IHRvIEguMjY0LiBkcmFmdC1pZXRmLXJ0Y3dlYi12aWRlbyBzZWN0aW9ucyA0LjIgLSA0LjQNCiBy ZW1haW4gc2tldGNoeSBhdCBiZXN0LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIGlmIHdlIGFyZSB0byBoYXZlIHRoZSBk aXNjdXNzaW9uIGFnYWluLCBpdCBzaG91bGQgb2NjdXIgaW4gdGhlIGNvbnRleHQgb2YgZGV0YWls ZWQgc3BlY2lmaWNhdGlvbnMgYW5kIGludGVyb3BlcmFiaWxpdHkgcmVwb3J0cy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBTdW4sIE9jdCAxOSwgMjAxNCBhdCA4OjE0IEFNLCBKb25hdGhhbiBSb3NlbmJl cmcgJmx0OzxhIGhyZWY9Im1haWx0bzpqZHJvc2VuQGpkcm9zZW4ubmV0IiB0YXJnZXQ9Il9ibGFu ayI+amRyb3NlbkBqZHJvc2VuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIGluIGZhdm9yIG9mIHRha2luZyBhbm90aGVy IHJ1biBhdCB0aGlzLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+VGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHJlcGVhdGVkbHkgc2FpZCB0aGF0IGFuIE1U SSBjb2RlYyBpcyBzb21ldGhpbmcgd2UgbmVlZCB0byBwcm9kdWNlLiBBbmQgaXRzIG9uZSBvZiB0 aGUgaXNzdWVzIGhvbGRpbmcgdXAgd2lkZXIgYWRvcHRpb24gb2YgdGhlIHRlY2hub2xvZ3kgKG5v dCB0aGUgb25seSBvbmUNCiBmb3Igc3VyZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQgdGhpbmdzIGhhdmUgY2hhbmdlZCBzaW5j ZSB0aGUgbGFzdCBtZWV0aW5nLCBhIHllYXIgYWdvIG5vdyAoTm92ZW1iZXIgaW4gVmFuY291dmVy KS4gQ2lzY28ncyBvcGVuMjY0IHBsdWdpbiBzaGlwcGVkIGFuZCBub3cganVzdCByZWNlbnRseSBp cyBpbnRlZ3JhdGVkIGludG8gRmlyZWZveC4gaU9TOCBzaGlwcGVkDQogd2l0aCBBUElzIGZvciBI MjY0LiBUaGVyZSBhcmUgb3RoZXIgdGhpbmdzIHdvcnRoIG5vdGluZy4gV2lsbCB0aGlzIGNoYW5n ZSB0aGUgbWluZHMgb2YgZXZlcnlvbmU/IFN1cmVseSBub3QuIFdpbGwgaXQgc3dheSBlbm91Z2gg Zm9yIHVzIHRvIGFjaGlldmUgcm91Z2ggY29uc2Vuc3VzPyBNYXliZS4gSU1ITyAtIHdvcnRoIGZp bmRpbmcgb3V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTYXQsIE9jdCAxOCwgMjAxNCBhdCA1OjA4IFBN LCBBbGV4YW5kcmUgR09VQUlMTEFSRCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFnb3VhaWxsYXJkQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFnb3VhaWxsYXJkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JiM0Mzsx IHRvIG5vdCBoYXZpbmcgTVRJIGNvZGVjIGRpc2N1c3Npb24gdW5sZXNzIHNvbWUgcHJvZ3Jlc3Mg aGFzIGJlZW4gbWFkZSBvbiBWUDggYXQgTVBFRy4mbmJzcDtBbnkgbmV3cyBvbiB0aGF0PyBJJ20g c2hhcmluZyBoYXJhbGQncyAmbmJzcDtmZWVsaW5nIHRoYXQgdGhlcmUgd2FzIG5vIGNoYW5nZSBv biB0aGUgbWVtYmVycw0KIHBvc2l0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBPY3QgMTcsIDIw MTQgYXQgOToyMiBQTSwgSGFyYWxkIEFsdmVzdHJhbmQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJh bGRAYWx2ZXN0cmFuZC5ubyIgdGFyZ2V0PSJfYmxhbmsiPmhhcmFsZEBhbHZlc3RyYW5kLm5vPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDEw LzE3LzIwMTQgMTI6MDIgQU0sIEJlcm5hcmQgQWJvYmEgd3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uZSB0aGluZyB3ZSBjb3VsZCBkbyBpbnN0ZWFkIG9mIHdh c3RpbmcgdGltZSBvbiBNVEkgaXMgdG8gYWN0dWFsbHkgbWFrZSBwcm9ncmVzcyBvbiBTZWN0aW9u cyA0LjIgLSA0LjQgb2YgZHJhZnQtSUVURi1SVENXRUItdmlkZW8sIHNvIHdlIGNvdWxkIGFjdHVh bGx5IGludGVyb3BlcmF0ZSByZWdhcmRsZXNzDQogb2YgdGhlIGNvZGVjLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpUaGUgYmlnIGFyZ3VtZW50IGZvciBhbiBN VEkgaXMgYWN0dWFsbHkgdGhlIG9uZSBzdGF0ZWQgaW4gLW92ZXJ2aWV3OiBJdCBndWFyZHMgYWdh aW5zdCBpbnRlcm9wZXJhYmlsaXR5IGZhaWx1cmUuPGJyPg0KPGJyPg0KSSB3b3VsZCBsaWtlIHRv IGhhdmUgYW4gZWNvc3lzdGVtIHdoZXJlIG9uZSBjYW4gZmllbGQgYSBib3gsIGNvbm5lY3QgaXQg dG8gZXZlcnl0aGluZyBlbHNlLCBhbmQgcnVuIHdlbGwgZm9yICpzb21lKiBsZXZlbCBvZiAmcXVv dDt3ZWxsJnF1b3Q7IC0gYW5kIEkgd291bGQgcHJlZmVyIHRoYXQgZWNvc3lzdGVtIHRvIGJlIG9u ZSB3aGVyZSBpdCdzIHBvc3NpYmxlIHRvIGZpZWxkIHRoZSBib3ggd2l0aG91dCBtYWtpbmcgcHJp b3IgYXJyYW5nZW1lbnRzIHdpdGggYW55b25lDQogYWJvdXQgbGljZW5zZXMuPGJyPg0KPGJyPg0K VGhpcyBhcmd1bWVudCBoYXNuJ3QgY2hhbmdlZCBvbmUgd2hpdCBzaW5jZSBsYXN0IHRpbWUgd2Ug ZGlzY3Vzc2VkIGl0LiBBbmQgSSBkb24ndCBzZWUgbXVjaCBtb3ZlbWVudCBvbiB0aGUgc3BlY2lm aWNzIG9mIHRoZSBwcm9wb3NhbHMgZWl0aGVyLjxicj4NCjxicj4NCldlJ2xsIGhhdmUgdG8gaW50 ZXJvcGVyYXRlIHdlbGwgd2l0aCB0aGUgY29kZWNzIHdlIGZpZWxkLiBTbyB1c2luZyBzb21lIHRp bWUgdG8gZGlzY3VzcyBkcmFmdC1pZXRmLXJ0Y3dlYi12aWRlbyBzZWVtcyB0byBtYWtlIHNlbnNl LiAoQW5kIDQuMSBpc24ndCBmaW5pc2hlZCBlaXRoZXIuIFRoZXJlJ3Mgb25lIHNlbnRlbmNlIHRo YXQgbmVlZHMgdG8gYmUgcmVtb3ZlZC4pPGJyPg0KPGJyPg0KSSB3b3VsZG4ndCBzYXkgSSdkIGJl IGhhcHB5IHRvIG5vdCBkaXNjdXNzIHRoaXMgaW4gSG9ub2x1bHUuIEJ1dCBJJ2QgcHJlZmVyIHRv IHJlLWRpc2N1c3MgYmFzZWQgb24gdGhlIGtub3dsZWRnZSB0aGF0IHNvbWUgc2lnbmlmaWNhbnQg cGxheWVycyBoYXZlIGFjdHVhbGx5IGNoYW5nZWQgdGhlaXIgbWluZHMuPGJyPg0KPGJyPg0KQXQg dGhlIG1vbWVudCwgSSBkb24ndCBzZWUgc2lnbnMgdGhhdCBhbnkgb2YgdGhlIHBvbGwgcmVzcG9u ZGVudHMgaGF2ZSBzYWlkICZxdW90O0kgaGF2ZSBjaGFuZ2VkIG15IG1pbmQmcXVvdDsuPHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCkhhcmFsZDwvc3Bhbj4gPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij5PbiBPY3QgMTYsIDIwMTQsIGF0IDI6MjggUE0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBo cmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFy dGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIDE2IE9jdG9iZXIgMjAxNCAxNDoxNywgTWF0dGhldyBLYXVm bWFuICZsdDs8YSBocmVmPSJtYWlsdG86bWF0dGhld0BtYXR0aGV3LmF0IiB0YXJnZXQ9Il9ibGFu ayI+bWF0dGhld0BtYXR0aGV3LmF0PC9hPiZndDsgd3JvdGU6PGJyPg0KQW5kIHRoYXQncyBiZWNh dXNlIHNvbWV0aGluZyBzdWJzdGFudGl2ZSBoYXMgY2hhbmdlZCwgb3Igc2ltcGx5IGJlY2F1c2U8 YnI+DQp3YXN0aW5nIHRoZSBXRyB0aW1lIG9uIHRoaXMgYWdhaW4gaXMgbW9yZSBlbnRlcnRhaW5p bmcgdGhhbiBhY3R1YWxseTxicj4NCmZpbmlzaGluZyBhIHNwZWNpZmljYXRpb24gdGhhdCBjYW4g YmUgaW5kZXBlbmRlbnRseSBpbXBsZW1lbnRlZCBieSBhbGw8YnI+DQpicm93c2VyIHZlbmRvcnM/ IChBIHNwZWNpZmljYXRpb24gdGhhdCB3ZSBhcmUgbm93aGVyZSBuZWFyIGhhdmluZywgYXMgZmFy IGFzPGJyPg0KSSBjYW4gdGVsbCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+UGVyc29uYWxseSwgSSd2ZSBmb3VuZCB0aGUgcmVwcmlldmUgZnJvbSB0aGlzIGZpZ2h0IHJl ZnJlc2hpbmcuJm5ic3A7IEFuZDxicj4NCml0IHdvdWxkIGFwcGVhciB0aGF0IHdlJ3ZlIG1hZGUg c29tZSByZWFsIHByb2dyZXNzIGFzIGEgcmVzdWx0LiZuYnNwOyBJJ2Q8YnI+DQpzdWdnZXN0IHRo YXQgaWYgd2UgZG9uJ3QgaGF2ZSBuZXcgaW5mb3JtYXRpb24sIHdlIGNvbnRpbnVlIHRvIHNwZW5k PGJyPg0Kb3VyIHRpbWUgcHJvZHVjdGl2ZWx5LiZuYnNwOyBJZiB3ZSBjYW4ndCBmaW5kIHRvcGlj cyB0byBvY2N1cHkgb3VyIG1lZXRpbmc8YnI+DQphZ2VuZGEgdGltZSwgdGhlbiBtYXliZSB3ZSBj YW4gZnJlZSBhbiBhZ2VuZGEgc2xvdC48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K cnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS0NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5B bGV4LiBHb3VhaWxsYXJkLCBQaEQsIFBoRCwgTUJBDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+Q1RPIC0gVGVtYXN5cyBDb21tdW5pY2F0aW9ucywgUydwb3JlIC8gTW91bnRhaW4gVmlldzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlByZXNpZGVudCAtIENvU01vIFNvZnR3YXJl LCBDYW1icmlkZ2UsIE1BPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGEgaHJl Zj0iaHR0cDovL3NnLmxpbmtlZGluLmNvbS9hZ291YWlsbGFyZCIgdGFyZ2V0PSJfYmxhbmsiPnNn LmxpbmtlZGluLmNvbS9hZ291YWlsbGFyZDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTQuNHB0O3ZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OlN5bWJvbDtjb2xvcjojMzMzMzMzIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOiMzMzMzMzMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9u dC1mYW1pbHk6aW5oZXJpdDtjb2xvcjojMzMzMzMzIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Kb25hdGhh biBSb3NlbmJlcmcsIFBoLkQuPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmpkcm9zZW5AamRyb3Nlbi5u ZXQiIHRhcmdldD0iX2JsYW5rIj5qZHJvc2VuQGpkcm9zZW4ubmV0PC9hPjxicj4NCjxhIGhyZWY9 Imh0dHA6Ly93d3cuamRyb3Nlbi5uZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lmpkcm9z ZW4ubmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRj d2ViQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS0gPC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5TdXJ2ZWlsbGFuY2Ug aXMgcGVydmFzaXZlLiBHbyBEYXJrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K cnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci PnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E36D1A4AE0B6AA4091F1728D584A6AD2400699DEfmsmsx118amrcor_-- From nobody Mon Oct 20 01:53:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6060C1A6FFB for ; Mon, 20 Oct 2014 01:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5olYmhxN8kv for ; Mon, 20 Oct 2014 01:53:01 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AF81A6FFA for ; Mon, 20 Oct 2014 01:53:00 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pv20so3475691lab.6 for ; Mon, 20 Oct 2014 01:52:59 -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=Lc7lN0FxdpE/dQPl+6y5KMEN4CU5XUzWSvFm+0vmbks=; b=WGFW8w9WLMM+CV7xzG6hZsN8OaRjHCZbLrlkXaIClbEi/uplS5v2PNRu38gtcU3ogi mw2XfntfdTcGMWau4lQGDTQ2b1TjfpJTmYLq2lncFgS/BSSg0Zqc5MWrn6gTGuEljJvS S7jCIaMNwsFZxq2Pg9or2Uz1YUsy8tOAx8L29Hsoju717AAUUb/INOwIxngvchPC3Hmt m4lXbYQfPvBcpZyTNcKWHYa1CicThsEDS2EraZ5KSdzqYloUMveIP8/ttFAsnKurf4Rw FHTaIxpuR8Aw3VWfoS6Y3rA+1gulRYEcoNBNvbYdclLNTjYlSKygIr4P1jbX9c+9tZm0 Na9Q== X-Received: by 10.152.163.101 with SMTP id yh5mr25175305lab.68.1413795179122; Mon, 20 Oct 2014 01:52:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.83.136 with HTTP; Mon, 20 Oct 2014 01:52:38 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> From: Barry Dingle Date: Mon, 20 Oct 2014 19:52:38 +1100 Message-ID: To: "Cavigioli, Chris" Content-Type: multipart/alternative; boundary=001a113369a66fddeb0505d6d745 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lemLlIjRn9s5vYcC_lId0BI2mdU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 08:53:06 -0000 --001a113369a66fddeb0505d6d745 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Chris, So you are saying that we should NOT have 'unqualified' MTI Audio and Video codecs. Rather, we should have 2 (or more) Network Scenarios and have Audio+Video MTI's for Each Network Scenario. Browsers that wish to support multiple Network Scenarios will support the MTI's for those Scenarios. Special Browsers - or a sub-set of a Browser - MAY support only specific Network Scenarios and their MTIs. This seems to make a lot of sense. Cheers, Barry Dingle Fixed - +61(0)3-9725-3937 Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Australia On Mon, Oct 20, 2014 at 6:09 PM, Cavigioli, Chris wrote: > No, not 2 discussions =E2=80=A6 but 2 MTI codecs. > > Given: > > - Industry is polarized c. 40% VP8 vs. c. 40% H.264 > > - Unlikely this will change > > - Every single mobile device (100%) of the billions out there > running a mobile OS (iOS, Android, Windows, BB OS, etc) will already > support H.264, AMR-xx since those are MTI for 3GPP and for the OS > > Then: > > - Why not support both: VP8, Opus =3D web; H.264, AMR/AMR-WB =3D L= TE > > - Every single mobile device and OS already deals with H.264+AMR > licensing for many years. > > - Being royalty free, incrementally adding VP8 and Opus shouldn=E2= =80=99t > be a major additional impact > > -chris > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Sunday, October 19, 2014 10:52 PM > *To:* Cavigioli, Chris > *Cc:* Harald Alvestrand; Bernard Aboba; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Looks like someone wants to have not just one, but two MTI codec > discussions... > > > > On Sun, Oct 19, 2014 at 6:20 PM, Cavigioli, Chris < > chris.cavigioli@intel.com> wrote: > > Harald said: > > =E2=80=9CWe made the mistake of having an MTI discussion previously with = not > enough details on that subject=E2=80=A6=E2=80=9D > > > > We didn=E2=80=99t have quantitative data earlier for a data-driven decisi= on. > Future Web =E2=80=93 LTE interop is important. A group of us in GSMA hav= e been > looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based > voice/video/messaging), specifically looking at user experience impact of > latency introduced by added in-network transcoding. GSMA has approved th= e > whitepaper and it is being prepared for public distribution. > > > > WebRTC =E2=80=93 LTE transcoding is now MANDATORY because of =E2=80=9CWeb= RTC Audio Codec > and Processing Requirements=E2=80=9D. > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio > codecs in WebRTC and in LTE are dissimilar. Thus, REGARDLESS of the vide= o > codecs, there is already a significant degradation imposed on Web =E2=80= =93 LTE > links if only MTI codecs are used. The only systems to avoid this are > those which implement OPTIONAL audio codecs to be transcoder-free with > LTE. The same can apply for video codecs. > > > > The GSMA whitepaper refers to: > > 1. Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by > 3GPP SA4 in August 2014. To paraphrase, performance objectives for maxim= um > VoLTE device delays in error and jitter free conditions and AMR speech > codec operation, the sum of the UE delays in sending and receiving > directions (TS + TR) should be =E2=89=A4 150ms. If this performance objec= tive > cannot be met, the sum of the UE delays in sending and receiving directio= ns > (TS + TR) shall in any case be =E2=89=A4 190ms. > > 2. OPUS =E2=80=93 AMR transcoding adds an additional 211.5 ms > implementation-agnostic (TS + TR) delay, including 40 ms for jitter > buffer and 40 ms for discontinuous reception (DRX). > > 3. To put these numbers in perspective, it is in general desirable to > minimize UE delays to ensure low enough end-to-end delays and hence a goo= d > conversational experience. Increasing delay causes people to double-talk > making conversations increasingly frustrating. Guidance to stay below 40= 0 > ms maximum one-way delay is found in ITU-T Recommendation G.114 and the > computational E-model is in ITU-T Recommendation G.107. > > > > This is a complex topic with many network factors in play. LTE operators > in 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS =E2=80=93 AM= R > transcoding in the network imposes an additional 211.5 ms on top of that, > just for audio. Optionally using AMR in WebRTC, those 211.5 ms can be > eliminated, delivering a superior end-user experience. > > > > CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a good > WebRTC =E2=80=93 LTE interop experience, emerging WebRTC systems must acc= ommodate > MTI codecs already deployed in the LTE domain and in mobile operating > systems, namely AMR/AMR-WB and H.264. > > > > POSITION: To be clear, several Intel SoCs launched at MWC this year for > smartphones and tablets support both VP8 and H.264 hardware encode and > decode =E2=80=93 so Intel is codec-neutral in this MTI debate. Additiona= lly, Intel > has high-performance solutions for transcoding. However, we wish to info= rm > the industry, with quantitative data, about impact to end-user experience > of mandating such transcoding so IETF can make a data-driven decision on > video codecs as well as reflect on the impact of already having mandated > transcoding on the audio side. > > > > Chris Cavigioli > > Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile > and Communications Group (MCG) > > +1 (415) 254-4545 mobile > > +1 (408) 653-8348 desk > > +1 (408) 884-2400 fax > > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review or distribution by others i= s > strictly prohibited. If you are not the intended recipient, please contac= t > the sender and delete all copies. > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Bernard > Aboba > *Sent:* Sunday, October 19, 2014 2:29 PM > *To:* Harald Alvestrand > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Harald said: > > > > "Bernard, > > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad....." > > > > [BA] I agree that the lack of interoperability is largely "codec > independent": that is, implementations based on different mechanisms fo= r > congestion control, repair, etc. will exhibit interoperability problems, > regardless of the codec chosen. The real test for RTCWEB will be to mov= e > beyond "interoperability of implementations sharing source code" to > "interoperability of independent implementations, based on open standards= ". > > > > > On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand > wrote: > > On 10/19/2014 05:43 PM, Bernard Aboba wrote: > > "And its one of the issues holding up wider adoption of the technology" > > > > [BA] Specifying an MTI encoder/decoder is not sufficient for > interoperability. It is also necessary to specify the transport in enoug= h > detail to allow independent implementations that interoperate well enough > to be usable in a wide variety of scenarios, including wireless networks > where loss is commonly experienced. > > > Bernard, > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad..... > > > > > > We made the mistake of having an MTI discussion previously with not enoug= h > details on that subject, particularly with respect to H.264. > draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > > > > So if we are to have the discussion again, it should occur in the context > of detailed specifications and interoperability reports. > > > > > > > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: > > I'm in favor of taking another run at this. > > > > The working group has repeatedly said that an MTI codec is something we > need to produce. And its one of the issues holding up wider adoption of t= he > technology (not the only one for sure). > > > > And things have changed since the last meeting, a year ago now (November > in Vancouver). Cisco's open264 plugin shipped and now just recently is > integrated into Firefox. iOS8 shipped with APIs for H264. There are other > things worth noting. Will this change the minds of everyone? Surely not. > Will it sway enough for us to achieve rough consensus? Maybe. IMHO - wort= h > finding out. > > > > On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < > agouaillard@gmail.com> wrote: > > +1 to not having MTI codec discussion unless some progress has been made > on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that ther= e > was no change on the members position. > > > > On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: > > On 10/17/2014 12:02 AM, Bernard Aboba wrote: > > One thing we could do instead of wasting time on MTI is to actually make > progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could > actually interoperate regardless of the codec. > > > The big argument for an MTI is actually the one stated in -overview: It > guards against interoperability failure. > > I would like to have an ecosystem where one can field a box, connect it t= o > everything else, and run well for *some* level of "well" - and I would > prefer that ecosystem to be one where it's possible to field the box > without making prior arrangements with anyone about licenses. > > This argument hasn't changed one whit since last time we discussed it. An= d > I don't see much movement on the specifics of the proposals either. > > We'll have to interoperate well with the codecs we field. So using some > time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn= 't > finished either. There's one sentence that needs to be removed.) > > I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd > prefer to re-discuss based on the knowledge that some significant players > have actually changed their minds. > > At the moment, I don't see signs that any of the poll respondents have > said "I have changed my mind". > > Harald > > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: > > On 16 October 2014 14:17, Matthew Kaufman wrote: > And that's because something substantive has changed, or simply because > wasting the WG time on this again is more entertaining than actually > finishing a specification that can be independently implemented by all > browser vendors? (A specification that we are nowhere near having, as far > as > I can tell) > > Personally, I've found the reprieve from this fight refreshing. And > it would appear that we've made some real progress as a result. I'd > suggest that if we don't have new information, we continue to spend > our time productively. If we can't find topics to occupy our meeting > agenda time, then maybe we can free an agenda slot. > > _______________________________________________ > 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 > > > > > > -- > > Alex. Gouaillard, PhD, PhD, MBA > > > -------------------------------------------------------------------------= ----------- > > CTO - Temasys Communications, S'pore / Mountain View > > President - CoSMo Software, Cambridge, MA > > > -------------------------------------------------------------------------= ----------- > > sg.linkedin.com/agouaillard > > =C2=B7 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > 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 > > > > -- > > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > 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 > > --001a113369a66fddeb0505d6d745 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chris,

So you are saying= that we should NOT have 'unqualified' MTI Audio and Video codecs. =

Rather, we should have 2 (or more) Network Scenarios and have= Audio+Video MTI's for Each Network Scenario.

Browsers th= at wish to support multiple Network Scenarios will support the MTI's fo= r those Scenarios. Special Browsers - or a sub-set of a Browser - MAY suppo= rt only specific Network Scenarios and their MTIs.

This seems= to make a lot of sense.

<= div>
Cheers,
Barry Dingle
Fixed - +61(0)3-9725-= 3937=C2=A0 =C2=A0 Mob - +61(0)41-911-7578=C2=A0=C2=A0
Fellow of Uni= versity of Melbourne, Australia

On Mon, Oct 20, 2014 at 6:09 PM, Cavigioli, = Chris <chris.cavigioli@intel.com> wrote:

No, not 2 discussions =E2= =80=A6 but 2 MTI codecs.=C2=A0

Given:=

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Industry is polarized = c. 40% VP8 vs. c. 40% H.264

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Unlikely this will cha= nge

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Every single mobile de= vice (100%) of the billions out there running a mobile OS (iOS, Android, Wi= ndows, BB OS, etc) will already support H.264, AMR-xx since those are MTI for 3GPP and for the OS

Then:<= /p>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Why not support both:= =C2=A0 VP8, Opus =3D web; H.264, AMR/AMR-WB =3D LTE

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Every single mobile de= vice and OS already deals with H.264+AMR licensing for many years.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Being royalty free, in= crementally adding VP8 and Opus shouldn=E2=80=99t be a major additional imp= act

-chris=

=C2=A0=

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Sunday, October 19, 2014 10:52 PM
To: Cavigioli, Chris
Cc: Harald Alvestrand; Bernard Aboba; rtcweb@ietf.org


Subject: Re: [rtcweb] Plan for MTI video codec?
<= /div>

=C2=A0

Looks like someone wants to have not just one, but t= wo MTI codec discussions...

=C2=A0

On Sun, Oct 19, 2014 at 6:20 PM, Cavigioli, Chris &l= t;chris.cavi= gioli@intel.com> wrote:

Harald said:=C2=A0

=E2=80=9CWe made the mistake of having an MTI discus= sion previously with not enough details on that subject=E2=80=A6=E2=80=9D

=C2=A0=

We didn=E2=80=99t have quan= titative data earlier for a data-driven decision.=C2=A0 Future Web =E2=80= =93 LTE interop is important.=C2=A0 A group of us in GSMA have been looking at WebRTC interop with LTE (where = 3GPP / GSMA defined IMS-based voice/video/messaging), specifically looking = at user experience impact of latency introduced by added in-network transco= ding.=C2=A0 GSMA has approved the whitepaper and it is being prepared for public distribution.=C2=A0 <= /u>

=C2=A0=

WebRTC =E2=80=93 LTE transc= oding is now MANDATORY because of =E2=80=9CWebRTC Audio Codec and Processin= g Requirements=E2=80=9D. http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where M= TI audio codecs in WebRTC and in LTE are dissimilar.=C2=A0 Thus, REGARDLESS= of the video codecs, there is already a significant degradation imposed on Web =E2=80=93 LTE links if only MTI cod= ecs are used.=C2=A0 The only systems to avoid this are those which implemen= t OPTIONAL audio codecs to be transcoder-free with LTE.=C2=A0 The same can = apply for video codecs.

=C2=A0=

The GSMA whitepaper refers = to:

1.=C2=A0=C2=A0=C2=A0=C2=A0 Quantitative voice-over-LTE (VoLTE) delay l= imits were agreed-to by 3GPP SA4 in August 2014.=C2=A0 To paraphrase, perfo= rmance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec operation, the sum of the = UE delays in sending and receiving directions (TS + TR) should be =E2=89=A4 150ms. If this performance objective cannot be met, = the sum of the UE delays in sending and receiving directions (TS + TR) shall in any case be = =E2=89=A4 190ms.

2.=C2=A0=C2=A0=C2=A0=C2=A0 OPUS =E2=80=93 AMR transcoding adds an addi= tional 211.5 ms implementation-agnostic (TS + TR) del= ay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.=C2=A0=C2=A0=C2=A0=C2=A0 To put these numbers in perspective, it is = in general desirable to minimize UE delays to ensure low enough end-to-end = delays and hence a good conversational experience.=C2=A0 Increasing delay causes people to double-talk making conversations increasingly frust= rating.=C2=A0 Guidance to stay below 400 ms maximum one-way delay is found = in ITU-T Recommendation G.114 and the computational E-model is in ITU-T Rec= ommendation G.107.

=C2=A0=

This is a complex topic wit= h many network factors in play.=C2=A0 LTE operators in 3GPP seek UE delays = (TS + TR) around 150 ms.=C2=A0 Adding OPUS =E2=80=93 AMR transcodin= g in the network imposes an additional 211.5 ms on top of that, just for au= dio.=C2=A0 Optionally using AMR in WebRTC, those 211.5 ms can be eliminated= , delivering a superior end-user experience.=C2=A0

=C2=A0=

CONCLUSION: =C2=A0regardles= s of MTI codec choices in WebRTC, to provide a good WebRTC =E2=80=93 LTE in= terop experience, emerging WebRTC systems must accommodate MTI codecs already deployed in th= e LTE domain and in mobile operating systems, namely AMR/AMR-WB and H.264.<= /span>

=C2=A0=

POSITION:=C2=A0 To be clear= , several Intel SoCs launched at MWC this year for smartphones and tablets = support both VP8 and H.264 hardware encode and decode =E2=80=93 so Intel is codec-= neutral in this MTI debate.=C2=A0 Additionally, Intel has high-performance = solutions for transcoding.=C2=A0 However, we wish to inform the industry, w= ith quantitative data, about impact to end-user experience of mandating such transcoding so IETF can make a data-driven decision on v= ideo codecs as well as reflect on the impact of already having mandated tra= nscoding on the audio side.

=C2=A0=

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group = (MCG)

+1 (415) 254-4545 mobile<= /u>

+1 (408) 653-8348 desk

+1 (408) 884-2400 fax=

This e-mail may contain confi= dential and privileged material for the sole use of the intended recipient(= s).=C2=A0 Any review or distribution by others is strictly prohibited. If you are no= t the intended recipient, please contact the sender and delete all copies.<= /span>

=C2=A0=

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?=

=C2=A0

Harald said:=C2=A0

=C2=A0

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....&qu= ot;

=C2=A0

[BA] =C2=A0I agree that the lack of interoperability= is largely "codec independent": =C2=A0 that is, implementations = based on different mechanisms for congestion control, repair, etc. will exhibit interoperability problems, regardless of the codec chosen. =C2=A0 = The real test for RTCWEB will be to move beyond "interoperability of i= mplementations sharing source code" =C2=A0to "interoperability of= independent implementations, based on open standards". =C2=A0=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:<= u>

"And its one of the issues holding up wider ado= ption of the technology"

=C2=A0

[BA] Specifying an MTI encoder/decoder is not suffic= ient for interoperability.=C2=A0 It is also necessary to specify the transp= ort in enough detail to allow independent implementations that interoperate well enough to be usable in a wide variety of scenarios,= including wireless networks where loss is commonly experienced.=C2=A0


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....

=C2=A0<= /p>

=C2=A0

We made the mistake of having an MTI discussion prev= iously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. =C2=A0

=C2=A0

So if we are to have the discussion again, it should= occur in the context of detailed specifications and interoperability repor= ts.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrose= n.net> wrote:

I'm in favor of taking another run at this.

=C2=A0

The working group has repeatedly said that an MTI co= dec is something we need to produce. And its one of the issues holding up w= ider adoption of the technology (not the only one for sure).

=C2=A0

And things have changed since the last meeting, a ye= ar ago now (November in Vancouver). Cisco's open264 plugin shipped and = now just recently is integrated into Firefox. iOS8 shipped with APIs for H264. There are other things worth noting. Will this change = the minds of everyone? Surely not. Will it sway enough for us to achieve ro= ugh consensus? Maybe. IMHO - worth finding out.

=C2=A0

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLAR= D <agouaillar= d@gmail.com> wrote:

+1 to not having MTI codec discussion unless some pr= ogress has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing= harald's =C2=A0feeling that there was no change on the members position.=C2=A0

=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:<= u>

One thing we could do instead of wasting time on MTI= is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-vi= deo, so we could actually interoperate regardless of the codec.


The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald

=C2=A0<= /p>

=C2=A0<= /p>

On Oct 16, 2014, at 2= :28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at>= ; wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)

Personally, I've found the reprieve from this fi= ght refreshing.=C2=A0 And
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



=C2=A0

--

Alex. Gouaillard, PhD,= PhD, MBA

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

CTO - Temasys Communic= ations, S'pore / Mountain View

President - CoSMo Soft= ware, Cambridge, MA

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0


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



=C2=A0

--


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

=C2=A0

=C2=A0<= /p> 

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

=C2=A0<= /p> 

-- 
Surveillance is pervasive. Go Dark.


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

=C2=A0


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

=C2=A0


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


--001a113369a66fddeb0505d6d745-- From nobody Mon Oct 20 03:06:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414FB1A7033 for ; Mon, 20 Oct 2014 03:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUgMskmDHBPR for ; Mon, 20 Oct 2014 03:05:54 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF69F1A7028 for ; Mon, 20 Oct 2014 03:05:53 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 4519FF4BCD7EE; Mon, 20 Oct 2014 10:05:49 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9KA5Zg6008913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 12:05:51 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 12:05:49 +0200 From: "DRAGE, Keith (Keith)" To: Victor Pascual , Ca By Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP669ol2Qsv7sEAECBFDAOBE1Cspw3bfYAgABSSQCAAA5FgIAAQIoAgAAzigCAABrFgIAAWhNA Date: Mon, 20 Oct 2014 10:05:48 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B262458@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> <09B5A70C-2537-412E-9898-E60E72008CBA@gmail.com> In-Reply-To: <09B5A70C-2537-412E-9898-E60E72008CBA@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qXJyILQ4CDaHg6ekt54rCDd_IXg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 10:06:00 -0000 Given that codecs appear in the end device and the 3GPP activity is to prov= ide a gateway, either the gateway provides transcoding or the two end devic= es use SDP to agree on a mutually acceptable codec.=20 Our view is that in many of these cases, it is perfectly possible for a web= RTC device and the 3GPP device to decide to use H.264 as the codec and will= do so, in order to avoid transcoding.=20 That will occur whatever is specified as an MTI video codec. Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Victor Pascual > Sent: 20 October 2014 07:00 > To: Ca By > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Plan for MTI video codec? >=20 > And that's what the 3GPP is doing for release 12:=20 > http://webrtchacks.com/ims-approach-webrtc/ >=20 > > On Oct 20, 2014, at 6:24 AM, Ca By wrote: > >=20 > > My guess is the IMS will change to interop with webrtc in=20 > an effort to stay relevant. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Mon Oct 20 05:02:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1581A6FED for ; Mon, 20 Oct 2014 05:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTkclODRyk8q for ; Mon, 20 Oct 2014 05:02:48 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0CA1A0111 for ; Mon, 20 Oct 2014 05:02:48 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ge10so3762716lab.38 for ; Mon, 20 Oct 2014 05:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tvpz9eLg+YEsiAPGDhNGRTpNhq+1i6mDnXhttCcVM98=; b=F40C9COha6r+h1+Jm6hqNt2l5+h0cwR/20i7I75FYY3SGafOd4Rv35ugny9eAaW0Sg ZS1bhQzxJ8xhp1Tt3/nLskWL155drKPvRN2rQLKfAiv3gqYBAhlwUukdKTOBfpo6uR2O z4ii9OsBA/GBAY90Gxq4gRIk09AKX4CwES4bV6O78oDaSEaMkIxvgXK1E+eSBOwGfcXH f+Qhc2MNL5+4GUw/MZ8m3LeBoTcKnSVGpv/SpsvihcP4s+BfSiinJecFUoUBCW3RdB3E arcJovOO7lwVIguEMGyJHv3Tid4cf69om/VXgnH8Clv2YPDMQ/PeOsIl1S3JJhCv7Hrz epZQ== MIME-Version: 1.0 X-Received: by 10.112.94.133 with SMTP id dc5mr26888060lbb.11.1413806566614; Mon, 20 Oct 2014 05:02:46 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Mon, 20 Oct 2014 05:02:46 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> Date: Mon, 20 Oct 2014 05:02:46 -0700 Message-ID: From: Martin Thomson To: Barry Dingle Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0X4t2biYNbsgKdWngi5Fp-zqVe8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 12:02:49 -0000 On 20 October 2014 01:52, Barry Dingle wrote: > Rather, we should have 2 (or more) Network Scenarios and have Audio+Video > MTI's for Each Network Scenario. Why should your network attachment conditions determine who you can talk to? From nobody Mon Oct 20 06:52:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377D21A8782 for ; Mon, 20 Oct 2014 06:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY7CLQdwvKFM for ; Mon, 20 Oct 2014 06:52:23 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2736F1A017E for ; Mon, 20 Oct 2014 06:52:20 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 20 Oct 2014 09:52:11 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 09:52:10 -0400 From: Andrew Allen To: "chris.cavigioli@intel.com" , "harald@alvestrand.no" , "bernard.aboba@gmail.com" Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP7G0L2AshmHfxg0SddD4axlD+Cg== Date: Mon, 20 Oct 2014 13:52:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2339941A25XMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mNQ3lM7zy0S06OgvQ8TaSmMCLdc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 13:52:28 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2339941A25XMB122CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpDaHJpcw0KDQpXaGF0IGlzIHRoZSBzY2VuYXJpbyB0aGF0IGRpY3RhdGVzIHRoZSBuZWVkIGZv ciBkaXJlY3QgdHJhbnNjb2RpbmcgYmV0d2VlbiBPUFVTIGFuZCBBTVI/DQoNCkFsbCBSVEN3ZWIg Y2xpZW50cyBNVVNUIHN1cHBvcnQgT1BVUyBzbyBmb3IgV2ViIGJyb3dzZXJzIG9uIG1vYmlsZSBM VEUgZGV2aWNlcyBPUFVTIGNhbiBiZSBuZWdvdGlhdGVkIHdpdGggbm9uIG1vYmlsZSBSVEN3ZWIg ZGV2aWNlcyBlbmQgdG8gZW5kLg0KDQpNeSBleHBlY3RhdGlvbiBpcyB0aGF0IGZvciBtb2JpbGUg ZGV2aWNlcyB0aGUgUlRDd2ViIGNsaWVudCB3aWxsIGFsc28gaGF2ZSBhY2Nlc3MgdG8gdGhlIGVt YmVkZGVkIEFNUiBjb2RlYyBzbyBtb2JpbGUgUlRDd2ViIGRldmljZXMgY2FuIGludGVyb3BlcmF0 ZSB1c2luZyBBTVIgd2l0aCBub24tUlRDd2ViIGVuYWJsZWQgbW9iaWxlIElNUyBkZXZpY2VzIHRo YXQgc3VwcG9ydCBBTVIuDQoNCkZvciBpbnRlcm9wZXJhdGlvbiBiZXR3ZWVuIG5vbiBtb2JpbGUg UlRDd2ViIGRldmljZXMgYW5kIG1vYmlsZSBub24gUlRDd2ViIElNUyBkZXZpY2VzIHRoZSBub24g bW9iaWxlIFJUQ3dlYiBkZXZpY2UgY2FuIHVzZSBHLjcxMSB0byB0aGUgdHJhbnNjb2RlciBmb3Ig dHJhbnNjb2RpbmcgdG8gQU1SIG9uIHRoZSBvdGhlciBzaWRlLiBXaGlsZSBub3QgaWRlYWwgdGhp cyB3aWxsIGJlIG5vIHdvcnNlIHRoYW4gbm9uIG1vYmlsZSBSVEN3ZWIgZGV2aWNlcyBpbnRlcm9w ZXJhdGluZyB3aXRoIGNpcmN1aXQgc3dpdGNoZWQgb25seSBtb2JpbGUgZGV2aWNlcyB3aGljaCB3 aWxsIGJlIGZvcmNlZCB0byBpbnRlcm9wZXJhdGUgdmlhIHRoZSBQU1ROLg0KDQpBcyBSVEN3ZWIg YmVjb21lcyB1bml2ZXJzYWwgb24gbW9iaWxlIGRldmljZXMgSSBleHBlY3QgdGhhdCBzdXBwb3J0 IGZvciBPUFVTIHdpbGwgYmVjb21lIG5hdGl2ZSBhbmQgbW9iaWxlIElNUyBkZXZpY2VzIHdpbGwg YWxzbyBiZSBhYmxlIHRvIHVzZSBPUFVTIGV2ZW4gd2hlbiBvcGVyYXRpbmcgd2l0aG91dCB0aGUg dXNlIG9mIHRoZSBicm93c2VyIChpLmUuIGluIG5vbiBSVEN3ZWIgbW9kZSkgZm9yIGJldHRlciBp bnRlcm9wZXJhdGlvbiB3aXRoIG5vbi1tb2JpbGUgUlRDd2ViIGRldmljZXMuDQoNClRoZSBsaWZl dGltZSBvZiBtb3N0IG1vYmlsZSBkZXZpY2VzIGlzIDIgeWVhcnMgb3IgbGVzcyBzbyB0aGlzIGlz IGxpa2VseSB0byBiZSBtYWlubHkgYSBzaG9ydCB0ZXJtIHRyYW5zaXRpb24gaXNzdWUgb25seS4N Cg0KQW5kcmV3DQoNCkZyb206IENhdmlnaW9saSwgQ2hyaXMgW21haWx0bzpjaHJpcy5jYXZpZ2lv bGlAaW50ZWwuY29tXQ0KU2VudDogU3VuZGF5LCBPY3RvYmVyIDE5LCAyMDE0IDA5OjIwIFBNIEVh c3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0 cmFuZC5ubz47IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPg0KQ2M6IHJ0 Y3dlYkBpZXRmLm9yZyA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFBs YW4gZm9yIE1USSB2aWRlbyBjb2RlYz8NCg0KSGFyYWxkIHNhaWQ6DQrigJxXZSBtYWRlIHRoZSBt aXN0YWtlIG9mIGhhdmluZyBhbiBNVEkgZGlzY3Vzc2lvbiBwcmV2aW91c2x5IHdpdGggbm90IGVu b3VnaCBkZXRhaWxzIG9uIHRoYXQgc3ViamVjdOKApuKAnQ0KDQpXZSBkaWRu4oCZdCBoYXZlIHF1 YW50aXRhdGl2ZSBkYXRhIGVhcmxpZXIgZm9yIGEgZGF0YS1kcml2ZW4gZGVjaXNpb24uICBGdXR1 cmUgV2ViIOKAkyBMVEUgaW50ZXJvcCBpcyBpbXBvcnRhbnQuICBBIGdyb3VwIG9mIHVzIGluIEdT TUEgaGF2ZSBiZWVuIGxvb2tpbmcgYXQgV2ViUlRDIGludGVyb3Agd2l0aCBMVEUgKHdoZXJlIDNH UFAgLyBHU01BIGRlZmluZWQgSU1TLWJhc2VkIHZvaWNlL3ZpZGVvL21lc3NhZ2luZyksIHNwZWNp ZmljYWxseSBsb29raW5nIGF0IHVzZXIgZXhwZXJpZW5jZSBpbXBhY3Qgb2YgbGF0ZW5jeSBpbnRy b2R1Y2VkIGJ5IGFkZGVkIGluLW5ldHdvcmsgdHJhbnNjb2RpbmcuICBHU01BIGhhcyBhcHByb3Zl ZCB0aGUgd2hpdGVwYXBlciBhbmQgaXQgaXMgYmVpbmcgcHJlcGFyZWQgZm9yIHB1YmxpYyBkaXN0 cmlidXRpb24uDQoNCldlYlJUQyDigJMgTFRFIHRyYW5zY29kaW5nIGlzIG5vdyBNQU5EQVRPUlkg YmVjYXVzZSBvZiDigJxXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nlc3NpbmcgUmVxdWlyZW1l bnRz4oCdLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1hdWRp by0wNSwgd2hlcmUgTVRJIGF1ZGlvIGNvZGVjcyBpbiBXZWJSVEMgYW5kIGluIExURSBhcmUgZGlz c2ltaWxhci4gIFRodXMsIFJFR0FSRExFU1Mgb2YgdGhlIHZpZGVvIGNvZGVjcywgdGhlcmUgaXMg YWxyZWFkeSBhIHNpZ25pZmljYW50IGRlZ3JhZGF0aW9uIGltcG9zZWQgb24gV2ViIOKAkyBMVEUg bGlua3MgaWYgb25seSBNVEkgY29kZWNzIGFyZSB1c2VkLiAgVGhlIG9ubHkgc3lzdGVtcyB0byBh dm9pZCB0aGlzIGFyZSB0aG9zZSB3aGljaCBpbXBsZW1lbnQgT1BUSU9OQUwgYXVkaW8gY29kZWNz IHRvIGJlIHRyYW5zY29kZXItZnJlZSB3aXRoIExURS4gIFRoZSBzYW1lIGNhbiBhcHBseSBmb3Ig dmlkZW8gY29kZWNzLg0KDQpUaGUgR1NNQSB3aGl0ZXBhcGVyIHJlZmVycyB0bzoNCg0KMS4gICAg IFF1YW50aXRhdGl2ZSB2b2ljZS1vdmVyLUxURSAoVm9MVEUpIGRlbGF5IGxpbWl0cyB3ZXJlIGFn cmVlZC10byBieSAzR1BQIFNBNCBpbiBBdWd1c3QgMjAxNC4gIFRvIHBhcmFwaHJhc2UsIHBlcmZv cm1hbmNlIG9iamVjdGl2ZXMgZm9yIG1heGltdW0gVm9MVEUgZGV2aWNlIGRlbGF5cyBpbiBlcnJv ciBhbmQgaml0dGVyIGZyZWUgY29uZGl0aW9ucyBhbmQgQU1SIHNwZWVjaCBjb2RlYyBvcGVyYXRp b24sIHRoZSBzdW0gb2YgdGhlIFVFIGRlbGF5cyBpbiBzZW5kaW5nIGFuZCByZWNlaXZpbmcgZGly ZWN0aW9ucyAoVFMgKyBUUikgc2hvdWxkIGJlIOKJpCAxNTBtcy4gSWYgdGhpcyBwZXJmb3JtYW5j ZSBvYmplY3RpdmUgY2Fubm90IGJlIG1ldCwgdGhlIHN1bSBvZiB0aGUgVUUgZGVsYXlzIGluIHNl bmRpbmcgYW5kIHJlY2VpdmluZyBkaXJlY3Rpb25zIChUUyArIFRSKSBzaGFsbCBpbiBhbnkgY2Fz ZSBiZSDiiaQgMTkwbXMuDQoNCjIuICAgICBPUFVTIOKAkyBBTVIgdHJhbnNjb2RpbmcgYWRkcyBh biBhZGRpdGlvbmFsIDIxMS41IG1zIGltcGxlbWVudGF0aW9uLWFnbm9zdGljIChUUyArIFRSKSBk ZWxheSwgaW5jbHVkaW5nIDQwIG1zIGZvciBqaXR0ZXIgYnVmZmVyIGFuZCA0MCBtcyBmb3IgZGlz Y29udGludW91cyByZWNlcHRpb24gKERSWCkuDQoNCjMuICAgICBUbyBwdXQgdGhlc2UgbnVtYmVy cyBpbiBwZXJzcGVjdGl2ZSwgaXQgaXMgaW4gZ2VuZXJhbCBkZXNpcmFibGUgdG8gbWluaW1pemUg VUUgZGVsYXlzIHRvIGVuc3VyZSBsb3cgZW5vdWdoIGVuZC10by1lbmQgZGVsYXlzIGFuZCBoZW5j ZSBhIGdvb2QgY29udmVyc2F0aW9uYWwgZXhwZXJpZW5jZS4gIEluY3JlYXNpbmcgZGVsYXkgY2F1 c2VzIHBlb3BsZSB0byBkb3VibGUtdGFsayBtYWtpbmcgY29udmVyc2F0aW9ucyBpbmNyZWFzaW5n bHkgZnJ1c3RyYXRpbmcuICBHdWlkYW5jZSB0byBzdGF5IGJlbG93IDQwMCBtcyBtYXhpbXVtIG9u ZS13YXkgZGVsYXkgaXMgZm91bmQgaW4gSVRVLVQgUmVjb21tZW5kYXRpb24gRy4xMTQgYW5kIHRo ZSBjb21wdXRhdGlvbmFsIEUtbW9kZWwgaXMgaW4gSVRVLVQgUmVjb21tZW5kYXRpb24gRy4xMDcu DQoNClRoaXMgaXMgYSBjb21wbGV4IHRvcGljIHdpdGggbWFueSBuZXR3b3JrIGZhY3RvcnMgaW4g cGxheS4gIExURSBvcGVyYXRvcnMgaW4gM0dQUCBzZWVrIFVFIGRlbGF5cyAoVFMgKyBUUikgYXJv dW5kIDE1MCBtcy4gIEFkZGluZyBPUFVTIOKAkyBBTVIgdHJhbnNjb2RpbmcgaW4gdGhlIG5ldHdv cmsgaW1wb3NlcyBhbiBhZGRpdGlvbmFsIDIxMS41IG1zIG9uIHRvcCBvZiB0aGF0LCBqdXN0IGZv ciBhdWRpby4gIE9wdGlvbmFsbHkgdXNpbmcgQU1SIGluIFdlYlJUQywgdGhvc2UgMjExLjUgbXMg Y2FuIGJlIGVsaW1pbmF0ZWQsIGRlbGl2ZXJpbmcgYSBzdXBlcmlvciBlbmQtdXNlciBleHBlcmll bmNlLg0KDQpDT05DTFVTSU9OOiAgcmVnYXJkbGVzcyBvZiBNVEkgY29kZWMgY2hvaWNlcyBpbiBX ZWJSVEMsIHRvIHByb3ZpZGUgYSBnb29kIFdlYlJUQyDigJMgTFRFIGludGVyb3AgZXhwZXJpZW5j ZSwgZW1lcmdpbmcgV2ViUlRDIHN5c3RlbXMgbXVzdCBhY2NvbW1vZGF0ZSBNVEkgY29kZWNzIGFs cmVhZHkgZGVwbG95ZWQgaW4gdGhlIExURSBkb21haW4gYW5kIGluIG1vYmlsZSBvcGVyYXRpbmcg c3lzdGVtcywgbmFtZWx5IEFNUi9BTVItV0IgYW5kIEguMjY0Lg0KDQpQT1NJVElPTjogIFRvIGJl IGNsZWFyLCBzZXZlcmFsIEludGVsIFNvQ3MgbGF1bmNoZWQgYXQgTVdDIHRoaXMgeWVhciBmb3Ig c21hcnRwaG9uZXMgYW5kIHRhYmxldHMgc3VwcG9ydCBib3RoIFZQOCBhbmQgSC4yNjQgaGFyZHdh cmUgZW5jb2RlIGFuZCBkZWNvZGUg4oCTIHNvIEludGVsIGlzIGNvZGVjLW5ldXRyYWwgaW4gdGhp cyBNVEkgZGViYXRlLiAgQWRkaXRpb25hbGx5LCBJbnRlbCBoYXMgaGlnaC1wZXJmb3JtYW5jZSBz b2x1dGlvbnMgZm9yIHRyYW5zY29kaW5nLiAgSG93ZXZlciwgd2Ugd2lzaCB0byBpbmZvcm0gdGhl IGluZHVzdHJ5LCB3aXRoIHF1YW50aXRhdGl2ZSBkYXRhLCBhYm91dCBpbXBhY3QgdG8gZW5kLXVz ZXIgZXhwZXJpZW5jZSBvZiBtYW5kYXRpbmcgc3VjaCB0cmFuc2NvZGluZyBzbyBJRVRGIGNhbiBt YWtlIGEgZGF0YS1kcml2ZW4gZGVjaXNpb24gb24gdmlkZW8gY29kZWNzIGFzIHdlbGwgYXMgcmVm bGVjdCBvbiB0aGUgaW1wYWN0IG9mIGFscmVhZHkgaGF2aW5nIG1hbmRhdGVkIHRyYW5zY29kaW5n IG9uIHRoZSBhdWRpbyBzaWRlLg0KDQpDaHJpcyBDYXZpZ2lvbGkNCkludGVsIENvcnAsIFN5c3Rl bSBBcmNoaXRlY3R1cmUgYW5kIFBsYW5uaW5nLCBWaWRlby9NdWx0aW1lZGlhLCBNb2JpbGUgYW5k IENvbW11bmljYXRpb25zIEdyb3VwIChNQ0cpDQorMSAoNDE1KSAyNTQtNDU0NSBtb2JpbGUNCisx ICg0MDgpIDY1My04MzQ4IGRlc2sNCisxICg0MDgpIDg4NC0yNDAwIGZheA0KVGhpcyBlLW1haWwg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gIEFueSByZXZpZXcgb3IgZGlz dHJpYnV0aW9uIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgYWxsIGNvcGllcy4NCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuYXJkIEFib2JhDQpTZW50OiBTdW5kYXksIE9jdG9i ZXIgMTksIDIwMTQgMjoyOSBQTQ0KVG86IEhhcmFsZCBBbHZlc3RyYW5kDQpDYzogcnRjd2ViQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUGxhbiBmb3IgTVRJIHZpZGVvIGNvZGVjPw0K DQpIYXJhbGQgc2FpZDoNCg0KIkJlcm5hcmQsDQoNCkkgdGhpbmsgdGhpcyBpcywgdG8gYSBsYXJn ZSBkZWdyZWUsIGNvZGVjIGluZGVwZW5kZW50Lg0KDQpXZSBoYXZlIGRlbW9uc3RyYXRlZCBpbnRl cm9wZXJhYmlsaXR5IG9uIFZQOCBiZXR3ZWVuIEZpcmVmb3ggYW5kIENocm9tZSwgYW5kIHVzYWdl IG9mIHZhcmlvdXMgbWVjaGFuaXNtcyBmb3IgY29uZ2VzdGlvbiBjb250cm9sIGFuZCByZXBhaXIg b2YgcGFja2V0IGxvc3MgYmVpbmcgYXBwbGllZCBpbiBsaXZlIHNlcnZpY2VzLg0KU28gaXQgY2Fu J3QgYmUgYWxsIGJhZC4uLi4uIg0KDQpbQkFdICBJIGFncmVlIHRoYXQgdGhlIGxhY2sgb2YgaW50 ZXJvcGVyYWJpbGl0eSBpcyBsYXJnZWx5ICJjb2RlYyBpbmRlcGVuZGVudCI6ICAgdGhhdCBpcywg aW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGRpZmZlcmVudCBtZWNoYW5pc21zIGZvciBjb25nZXN0 aW9uIGNvbnRyb2wsIHJlcGFpciwgZXRjLiB3aWxsIGV4aGliaXQgaW50ZXJvcGVyYWJpbGl0eSBw cm9ibGVtcywgcmVnYXJkbGVzcyBvZiB0aGUgY29kZWMgY2hvc2VuLiAgIFRoZSByZWFsIHRlc3Qg Zm9yIFJUQ1dFQiB3aWxsIGJlIHRvIG1vdmUgYmV5b25kICJpbnRlcm9wZXJhYmlsaXR5IG9mIGlt cGxlbWVudGF0aW9ucyBzaGFyaW5nIHNvdXJjZSBjb2RlIiAgdG8gImludGVyb3BlcmFiaWxpdHkg b2YgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zLCBiYXNlZCBvbiBvcGVuIHN0YW5kYXJkcyIu DQoNCk9uIFN1biwgT2N0IDE5LCAyMDE0IGF0IDE6MzggUE0sIEhhcmFsZCBBbHZlc3RyYW5kIDxo YXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8+PiB3cm90ZToN Ck9uIDEwLzE5LzIwMTQgMDU6NDMgUE0sIEJlcm5hcmQgQWJvYmEgd3JvdGU6DQoiQW5kIGl0cyBv bmUgb2YgdGhlIGlzc3VlcyBob2xkaW5nIHVwIHdpZGVyIGFkb3B0aW9uIG9mIHRoZSB0ZWNobm9s b2d5Ig0KDQpbQkFdIFNwZWNpZnlpbmcgYW4gTVRJIGVuY29kZXIvZGVjb2RlciBpcyBub3Qgc3Vm ZmljaWVudCBmb3IgaW50ZXJvcGVyYWJpbGl0eS4gIEl0IGlzIGFsc28gbmVjZXNzYXJ5IHRvIHNw ZWNpZnkgdGhlIHRyYW5zcG9ydCBpbiBlbm91Z2ggZGV0YWlsIHRvIGFsbG93IGluZGVwZW5kZW50 IGltcGxlbWVudGF0aW9ucyB0aGF0IGludGVyb3BlcmF0ZSB3ZWxsIGVub3VnaCB0byBiZSB1c2Fi bGUgaW4gYSB3aWRlIHZhcmlldHkgb2Ygc2NlbmFyaW9zLCBpbmNsdWRpbmcgd2lyZWxlc3MgbmV0 d29ya3Mgd2hlcmUgbG9zcyBpcyBjb21tb25seSBleHBlcmllbmNlZC4NCg0KQmVybmFyZCwNCg0K SSB0aGluayB0aGlzIGlzLCB0byBhIGxhcmdlIGRlZ3JlZSwgY29kZWMgaW5kZXBlbmRlbnQuDQoN CldlIGhhdmUgZGVtb25zdHJhdGVkIGludGVyb3BlcmFiaWxpdHkgb24gVlA4IGJldHdlZW4gRmly ZWZveCBhbmQgQ2hyb21lLCBhbmQgdXNhZ2Ugb2YgdmFyaW91cyBtZWNoYW5pc21zIGZvciBjb25n ZXN0aW9uIGNvbnRyb2wgYW5kIHJlcGFpciBvZiBwYWNrZXQgbG9zcyBiZWluZyBhcHBsaWVkIGlu IGxpdmUgc2VydmljZXMuDQoNClNvIGl0IGNhbid0IGJlIGFsbCBiYWQuLi4uLg0KDQoNCg0KDQpX ZSBtYWRlIHRoZSBtaXN0YWtlIG9mIGhhdmluZyBhbiBNVEkgZGlzY3Vzc2lvbiBwcmV2aW91c2x5 IHdpdGggbm90IGVub3VnaCBkZXRhaWxzIG9uIHRoYXQgc3ViamVjdCwgcGFydGljdWxhcmx5IHdp dGggcmVzcGVjdCB0byBILjI2NC4gZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8gc2VjdGlvbnMgNC4y IC0gNC40IHJlbWFpbiBza2V0Y2h5IGF0IGJlc3QuDQoNClNvIGlmIHdlIGFyZSB0byBoYXZlIHRo ZSBkaXNjdXNzaW9uIGFnYWluLCBpdCBzaG91bGQgb2NjdXIgaW4gdGhlIGNvbnRleHQgb2YgZGV0 YWlsZWQgc3BlY2lmaWNhdGlvbnMgYW5kIGludGVyb3BlcmFiaWxpdHkgcmVwb3J0cy4NCg0KDQoN Cg0KDQpPbiBTdW4sIE9jdCAxOSwgMjAxNCBhdCA4OjE0IEFNLCBKb25hdGhhbiBSb3NlbmJlcmcg PGpkcm9zZW5AamRyb3Nlbi5uZXQ8bWFpbHRvOmpkcm9zZW5AamRyb3Nlbi5uZXQ+PiB3cm90ZToN CkknbSBpbiBmYXZvciBvZiB0YWtpbmcgYW5vdGhlciBydW4gYXQgdGhpcy4NCg0KVGhlIHdvcmtp bmcgZ3JvdXAgaGFzIHJlcGVhdGVkbHkgc2FpZCB0aGF0IGFuIE1USSBjb2RlYyBpcyBzb21ldGhp bmcgd2UgbmVlZCB0byBwcm9kdWNlLiBBbmQgaXRzIG9uZSBvZiB0aGUgaXNzdWVzIGhvbGRpbmcg dXAgd2lkZXIgYWRvcHRpb24gb2YgdGhlIHRlY2hub2xvZ3kgKG5vdCB0aGUgb25seSBvbmUgZm9y IHN1cmUpLg0KDQpBbmQgdGhpbmdzIGhhdmUgY2hhbmdlZCBzaW5jZSB0aGUgbGFzdCBtZWV0aW5n LCBhIHllYXIgYWdvIG5vdyAoTm92ZW1iZXIgaW4gVmFuY291dmVyKS4gQ2lzY28ncyBvcGVuMjY0 IHBsdWdpbiBzaGlwcGVkIGFuZCBub3cganVzdCByZWNlbnRseSBpcyBpbnRlZ3JhdGVkIGludG8g RmlyZWZveC4gaU9TOCBzaGlwcGVkIHdpdGggQVBJcyBmb3IgSDI2NC4gVGhlcmUgYXJlIG90aGVy IHRoaW5ncyB3b3J0aCBub3RpbmcuIFdpbGwgdGhpcyBjaGFuZ2UgdGhlIG1pbmRzIG9mIGV2ZXJ5 b25lPyBTdXJlbHkgbm90LiBXaWxsIGl0IHN3YXkgZW5vdWdoIGZvciB1cyB0byBhY2hpZXZlIHJv dWdoIGNvbnNlbnN1cz8gTWF5YmUuIElNSE8gLSB3b3J0aCBmaW5kaW5nIG91dC4NCg0KT24gU2F0 LCBPY3QgMTgsIDIwMTQgYXQgNTowOCBQTSwgQWxleGFuZHJlIEdPVUFJTExBUkQgPGFnb3VhaWxs YXJkQGdtYWlsLmNvbTxtYWlsdG86YWdvdWFpbGxhcmRAZ21haWwuY29tPj4gd3JvdGU6DQorMSB0 byBub3QgaGF2aW5nIE1USSBjb2RlYyBkaXNjdXNzaW9uIHVubGVzcyBzb21lIHByb2dyZXNzIGhh cyBiZWVuIG1hZGUgb24gVlA4IGF0IE1QRUcuIEFueSBuZXdzIG9uIHRoYXQ/IEknbSBzaGFyaW5n IGhhcmFsZCdzICBmZWVsaW5nIHRoYXQgdGhlcmUgd2FzIG5vIGNoYW5nZSBvbiB0aGUgbWVtYmVy cyBwb3NpdGlvbi4NCg0KT24gRnJpLCBPY3QgMTcsIDIwMTQgYXQgOToyMiBQTSwgSGFyYWxkIEFs dmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5u bz4+IHdyb3RlOg0KT24gMTAvMTcvMjAxNCAxMjowMiBBTSwgQmVybmFyZCBBYm9iYSB3cm90ZToN Ck9uZSB0aGluZyB3ZSBjb3VsZCBkbyBpbnN0ZWFkIG9mIHdhc3RpbmcgdGltZSBvbiBNVEkgaXMg dG8gYWN0dWFsbHkgbWFrZSBwcm9ncmVzcyBvbiBTZWN0aW9ucyA0LjIgLSA0LjQgb2YgZHJhZnQt SUVURi1SVENXRUItdmlkZW8sIHNvIHdlIGNvdWxkIGFjdHVhbGx5IGludGVyb3BlcmF0ZSByZWdh cmRsZXNzIG9mIHRoZSBjb2RlYy4NCg0KVGhlIGJpZyBhcmd1bWVudCBmb3IgYW4gTVRJIGlzIGFj dHVhbGx5IHRoZSBvbmUgc3RhdGVkIGluIC1vdmVydmlldzogSXQgZ3VhcmRzIGFnYWluc3QgaW50 ZXJvcGVyYWJpbGl0eSBmYWlsdXJlLg0KDQpJIHdvdWxkIGxpa2UgdG8gaGF2ZSBhbiBlY29zeXN0 ZW0gd2hlcmUgb25lIGNhbiBmaWVsZCBhIGJveCwgY29ubmVjdCBpdCB0byBldmVyeXRoaW5nIGVs c2UsIGFuZCBydW4gd2VsbCBmb3IgKnNvbWUqIGxldmVsIG9mICJ3ZWxsIiAtIGFuZCBJIHdvdWxk IHByZWZlciB0aGF0IGVjb3N5c3RlbSB0byBiZSBvbmUgd2hlcmUgaXQncyBwb3NzaWJsZSB0byBm aWVsZCB0aGUgYm94IHdpdGhvdXQgbWFraW5nIHByaW9yIGFycmFuZ2VtZW50cyB3aXRoIGFueW9u ZSBhYm91dCBsaWNlbnNlcy4NCg0KVGhpcyBhcmd1bWVudCBoYXNuJ3QgY2hhbmdlZCBvbmUgd2hp dCBzaW5jZSBsYXN0IHRpbWUgd2UgZGlzY3Vzc2VkIGl0LiBBbmQgSSBkb24ndCBzZWUgbXVjaCBt b3ZlbWVudCBvbiB0aGUgc3BlY2lmaWNzIG9mIHRoZSBwcm9wb3NhbHMgZWl0aGVyLg0KDQpXZSds bCBoYXZlIHRvIGludGVyb3BlcmF0ZSB3ZWxsIHdpdGggdGhlIGNvZGVjcyB3ZSBmaWVsZC4gU28g dXNpbmcgc29tZSB0aW1lIHRvIGRpc2N1c3MgZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8gc2VlbXMg dG8gbWFrZSBzZW5zZS4gKEFuZCA0LjEgaXNuJ3QgZmluaXNoZWQgZWl0aGVyLiBUaGVyZSdzIG9u ZSBzZW50ZW5jZSB0aGF0IG5lZWRzIHRvIGJlIHJlbW92ZWQuKQ0KDQpJIHdvdWxkbid0IHNheSBJ J2QgYmUgaGFwcHkgdG8gbm90IGRpc2N1c3MgdGhpcyBpbiBIb25vbHVsdS4gQnV0IEknZCBwcmVm ZXIgdG8gcmUtZGlzY3VzcyBiYXNlZCBvbiB0aGUga25vd2xlZGdlIHRoYXQgc29tZSBzaWduaWZp Y2FudCBwbGF5ZXJzIGhhdmUgYWN0dWFsbHkgY2hhbmdlZCB0aGVpciBtaW5kcy4NCg0KQXQgdGhl IG1vbWVudCwgSSBkb24ndCBzZWUgc2lnbnMgdGhhdCBhbnkgb2YgdGhlIHBvbGwgcmVzcG9uZGVu dHMgaGF2ZSBzYWlkICJJIGhhdmUgY2hhbmdlZCBteSBtaW5kIi4NCg0KSGFyYWxkDQoNCg0KDQoN Ck9uIE9jdCAxNiwgMjAxNCwgYXQgMjoyOCBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9t c29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpP biAxNiBPY3RvYmVyIDIwMTQgMTQ6MTcsIE1hdHRoZXcgS2F1Zm1hbiA8bWF0dGhld0BtYXR0aGV3 LmF0PG1haWx0bzptYXR0aGV3QG1hdHRoZXcuYXQ+PiB3cm90ZToNCkFuZCB0aGF0J3MgYmVjYXVz ZSBzb21ldGhpbmcgc3Vic3RhbnRpdmUgaGFzIGNoYW5nZWQsIG9yIHNpbXBseSBiZWNhdXNlDQp3 YXN0aW5nIHRoZSBXRyB0aW1lIG9uIHRoaXMgYWdhaW4gaXMgbW9yZSBlbnRlcnRhaW5pbmcgdGhh biBhY3R1YWxseQ0KZmluaXNoaW5nIGEgc3BlY2lmaWNhdGlvbiB0aGF0IGNhbiBiZSBpbmRlcGVu ZGVudGx5IGltcGxlbWVudGVkIGJ5IGFsbA0KYnJvd3NlciB2ZW5kb3JzPyAoQSBzcGVjaWZpY2F0 aW9uIHRoYXQgd2UgYXJlIG5vd2hlcmUgbmVhciBoYXZpbmcsIGFzIGZhciBhcw0KSSBjYW4gdGVs bCkNClBlcnNvbmFsbHksIEkndmUgZm91bmQgdGhlIHJlcHJpZXZlIGZyb20gdGhpcyBmaWdodCBy ZWZyZXNoaW5nLiAgQW5kDQppdCB3b3VsZCBhcHBlYXIgdGhhdCB3ZSd2ZSBtYWRlIHNvbWUgcmVh bCBwcm9ncmVzcyBhcyBhIHJlc3VsdC4gIEknZA0Kc3VnZ2VzdCB0aGF0IGlmIHdlIGRvbid0IGhh dmUgbmV3IGluZm9ybWF0aW9uLCB3ZSBjb250aW51ZSB0byBzcGVuZA0Kb3VyIHRpbWUgcHJvZHVj dGl2ZWx5LiAgSWYgd2UgY2FuJ3QgZmluZCB0b3BpY3MgdG8gb2NjdXB5IG91ciBtZWV0aW5nDQph Z2VuZGEgdGltZSwgdGhlbiBtYXliZSB3ZSBjYW4gZnJlZSBhbiBhZ2VuZGEgc2xvdC4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWls aW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViDQoNCg0KDQotLQ0KQWxleC4gR291YWlsbGFyZCwgUGhELCBQaEQsIE1CQQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDVE8gLSBUZW1hc3lzIENvbW11bmljYXRpb25z LCBTJ3BvcmUgLyBNb3VudGFpbiBWaWV3DQpQcmVzaWRlbnQgLSBDb1NNbyBTb2Z0d2FyZSwgQ2Ft YnJpZGdlLCBNQQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpzZy5saW5rZWRpbi5jb20v YWdvdWFpbGxhcmQ8aHR0cDovL3NnLmxpbmtlZGluLmNvbS9hZ291YWlsbGFyZD4NCsK3DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFp bGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQotLQ0KSm9uYXRo YW4gUm9zZW5iZXJnLCBQaC5ELg0KamRyb3NlbkBqZHJvc2VuLm5ldDxtYWlsdG86amRyb3NlbkBq ZHJvc2VuLm5ldD4NCmh0dHA6Ly93d3cuamRyb3Nlbi5uZXQNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCg0KcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KLS0NCg0KU3VydmVpbGxhbmNlIGlzIHBlcnZhc2l2 ZS4gR28gRGFyay4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIN Cg0K --_000_BBF5DDFE515C3946BC18D733B20DAD2339941A25XMB122CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTppbmhl cml0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5v c2UtMToyIDExIDYgOSA0IDUgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkFu ZGFsdXM7DQoJcGFub3NlLTE6MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5ob2VuemINCgl7bXNv LXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDg5MDk3NjI0Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTgyNjM0MTczMjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6NjgwODYxODA2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTM0OTQ3ODcyIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxmb250IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48YnI+DQpDaHJpczxicj4NCjxicj4NCldoYXQgaXMgdGhlIHNjZW5hcmlvIHRoYXQgZGljdGF0 ZXMgdGhlIG5lZWQgZm9yIGRpcmVjdCB0cmFuc2NvZGluZyBiZXR3ZWVuIE9QVVMgYW5kIEFNUj8N Cjxicj4NCjxicj4NCkFsbCBSVEN3ZWIgY2xpZW50cyBNVVNUIHN1cHBvcnQgT1BVUyBzbyBmb3Ig V2ViIGJyb3dzZXJzIG9uIG1vYmlsZSBMVEUgZGV2aWNlcyBPUFVTIGNhbiBiZSBuZWdvdGlhdGVk IHdpdGggbm9uIG1vYmlsZSBSVEN3ZWIgZGV2aWNlcyBlbmQgdG8gZW5kLg0KPGJyPg0KPGJyPg0K TXkgZXhwZWN0YXRpb24gaXMgdGhhdCBmb3IgbW9iaWxlIGRldmljZXMgdGhlIFJUQ3dlYiBjbGll bnQgd2lsbCBhbHNvIGhhdmUgYWNjZXNzIHRvIHRoZSBlbWJlZGRlZCBBTVIgY29kZWMgc28gbW9i aWxlIFJUQ3dlYiBkZXZpY2VzIGNhbiBpbnRlcm9wZXJhdGUgdXNpbmcgQU1SIHdpdGggbm9uLVJU Q3dlYiBlbmFibGVkIG1vYmlsZSBJTVMgZGV2aWNlcyB0aGF0IHN1cHBvcnQgQU1SLjxicj4NCjxi cj4NCkZvciBpbnRlcm9wZXJhdGlvbiBiZXR3ZWVuIG5vbiBtb2JpbGUgUlRDd2ViIGRldmljZXMg YW5kIG1vYmlsZSBub24gUlRDd2ViIElNUyBkZXZpY2VzIHRoZSBub24gbW9iaWxlIFJUQ3dlYiBk ZXZpY2UgY2FuIHVzZSBHLjcxMSB0byB0aGUgdHJhbnNjb2RlciBmb3IgdHJhbnNjb2RpbmcgdG8g QU1SIG9uIHRoZSBvdGhlciBzaWRlLiBXaGlsZSBub3QgaWRlYWwgdGhpcyB3aWxsIGJlIG5vIHdv cnNlIHRoYW4gbm9uIG1vYmlsZSBSVEN3ZWIgZGV2aWNlcw0KIGludGVyb3BlcmF0aW5nIHdpdGgg Y2lyY3VpdCBzd2l0Y2hlZCBvbmx5IG1vYmlsZSBkZXZpY2VzIHdoaWNoIHdpbGwgYmUgZm9yY2Vk IHRvIGludGVyb3BlcmF0ZSB2aWEgdGhlIFBTVE4uPGJyPg0KPGJyPg0KQXMgUlRDd2ViIGJlY29t ZXMgdW5pdmVyc2FsIG9uIG1vYmlsZSBkZXZpY2VzIEkgZXhwZWN0IHRoYXQgc3VwcG9ydCBmb3Ig T1BVUyB3aWxsIGJlY29tZSBuYXRpdmUgYW5kIG1vYmlsZSBJTVMgZGV2aWNlcyB3aWxsIGFsc28g YmUgYWJsZSB0byB1c2UgT1BVUyBldmVuIHdoZW4gb3BlcmF0aW5nIHdpdGhvdXQgdGhlIHVzZSBv ZiB0aGUgYnJvd3NlciAoaS5lLiBpbiBub24gUlRDd2ViIG1vZGUpIGZvciBiZXR0ZXIgaW50ZXJv cGVyYXRpb24gd2l0aA0KIG5vbi1tb2JpbGUgUlRDd2ViIGRldmljZXMuIDxicj4NCjxicj4NClRo ZSBsaWZldGltZSBvZiBtb3N0IG1vYmlsZSBkZXZpY2VzIGlzIDIgeWVhcnMgb3IgbGVzcyBzbyB0 aGlzIGlzIGxpa2VseSB0byBiZSBtYWlubHkgYSBzaG9ydCB0ZXJtIHRyYW5zaXRpb24gaXNzdWUg b25seS48YnI+DQo8YnI+DQpBbmRyZXc8L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiPkZyb208L2I+ OiBDYXZpZ2lvbGksIENocmlzIFttYWlsdG86Y2hyaXMuY2F2aWdpb2xpQGludGVsLmNvbV0NCjxi cj4NCjxiPlNlbnQ8L2I+OiBTdW5kYXksIE9jdG9iZXIgMTksIDIwMTQgMDk6MjAgUE0gRWFzdGVy biBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG88L2I+OiBIYXJhbGQgQWx2ZXN0cmFuZCAmbHQ7aGFy YWxkQGFsdmVzdHJhbmQubm8mZ3Q7OyBCZXJuYXJkIEFib2JhICZsdDtiZXJuYXJkLmFib2JhQGdt YWlsLmNvbSZndDsNCjxicj4NCjxiPkNjPC9iPjogcnRjd2ViQGlldGYub3JnICZsdDtydGN3ZWJA aWV0Zi5vcmcmZ3Q7IDxicj4NCjxiPlN1YmplY3Q8L2I+OiBSZTogW3J0Y3dlYl0gUGxhbiBmb3Ig TVRJIHZpZGVvIGNvZGVjPyA8YnI+DQo8L2ZvbnQ+Jm5ic3A7PGJyPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IYXJhbGQgc2FpZDombmJzcDsNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFdlIG1hZGUgdGhlIG1pc3Rha2Ug b2YgaGF2aW5nIGFuIE1USSBkaXNjdXNzaW9uIHByZXZpb3VzbHkgd2l0aCBub3QgZW5vdWdoIGRl dGFpbHMgb24gdGhhdCBzdWJqZWN04oCm4oCdPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+V2UgZGlkbuKAmXQgaGF2ZSBxdWFudGl0YXRpdmUgZGF0YSBlYXJs aWVyIGZvciBhIGRhdGEtZHJpdmVuIGRlY2lzaW9uLiZuYnNwOyBGdXR1cmUgV2ViIOKAkyBMVEUg aW50ZXJvcCBpcyBpbXBvcnRhbnQuJm5ic3A7IEEgZ3JvdXAgb2YgdXMgaW4gR1NNQSBoYXZlIGJl ZW4gbG9va2luZyBhdCBXZWJSVEMNCiBpbnRlcm9wIHdpdGggTFRFICh3aGVyZSAzR1BQIC8gR1NN QSBkZWZpbmVkIElNUy1iYXNlZCB2b2ljZS92aWRlby9tZXNzYWdpbmcpLCBzcGVjaWZpY2FsbHkg bG9va2luZyBhdCB1c2VyIGV4cGVyaWVuY2UgaW1wYWN0IG9mIGxhdGVuY3kgaW50cm9kdWNlZCBi eSBhZGRlZCBpbi1uZXR3b3JrIHRyYW5zY29kaW5nLiZuYnNwOyBHU01BIGhhcyBhcHByb3ZlZCB0 aGUgd2hpdGVwYXBlciBhbmQgaXQgaXMgYmVpbmcgcHJlcGFyZWQgZm9yIHB1YmxpYyBkaXN0cmli dXRpb24uJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+V2ViUlRDIOKAkyBMVEUgdHJhbnNjb2RpbmcgaXMgbm93IE1B TkRBVE9SWSBiZWNhdXNlIG9mIOKAnFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJvY2Vzc2luZyBS ZXF1aXJlbWVudHPigJ0uDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXJ0Y3dlYi1hdWRpby0wNSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1ydGN3ZWItYXVkaW8tMDU8L2E+LCB3aGVyZSBNVEkgYXVkaW8gY29kZWNzIGluIFdlYlJU QyBhbmQgaW4gTFRFIGFyZSBkaXNzaW1pbGFyLiZuYnNwOyBUaHVzLCBSRUdBUkRMRVNTIG9mIHRo ZSB2aWRlbyBjb2RlY3MsIHRoZXJlIGlzIGFscmVhZHkgYSBzaWduaWZpY2FudCBkZWdyYWRhdGlv bg0KIGltcG9zZWQgb24gV2ViIOKAkyBMVEUgbGlua3MgaWYgb25seSBNVEkgY29kZWNzIGFyZSB1 c2VkLiZuYnNwOyBUaGUgb25seSBzeXN0ZW1zIHRvIGF2b2lkIHRoaXMgYXJlIHRob3NlIHdoaWNo IGltcGxlbWVudCBPUFRJT05BTCBhdWRpbyBjb2RlY3MgdG8gYmUgdHJhbnNjb2Rlci1mcmVlIHdp dGggTFRFLiZuYnNwOyBUaGUgc2FtZSBjYW4gYXBwbHkgZm9yIHZpZGVvIGNvZGVjcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhlIEdTTUEgd2hpdGVwYXBlciByZWZlcnMgdG86PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UXVhbnRpdGF0aXZlIHZvaWNlLW92 ZXItTFRFIChWb0xURSkgZGVsYXkgbGltaXRzIHdlcmUgYWdyZWVkLXRvIGJ5IDNHUFAgU0E0IGlu IEF1Z3VzdCAyMDE0LiZuYnNwOyBUbyBwYXJhcGhyYXNlLCBwZXJmb3JtYW5jZSBvYmplY3RpdmVz IGZvciBtYXhpbXVtIFZvTFRFDQogZGV2aWNlIGRlbGF5cyBpbiBlcnJvciBhbmQgaml0dGVyIGZy ZWUgY29uZGl0aW9ucyBhbmQgQU1SIHNwZWVjaCBjb2RlYyBvcGVyYXRpb24sIHRoZSBzdW0gb2Yg dGhlIFVFIGRlbGF5cyBpbiBzZW5kaW5nIGFuZCByZWNlaXZpbmcgZGlyZWN0aW9ucyAoVDxzdWI+ Uzwvc3ViPiAmIzQzOyBUPHN1Yj5SPC9zdWI+KSBzaG91bGQgYmUg4omkIDE1MG1zLiBJZiB0aGlz IHBlcmZvcm1hbmNlIG9iamVjdGl2ZSBjYW5ub3QgYmUgbWV0LCB0aGUgc3VtIG9mIHRoZSBVRQ0K IGRlbGF5cyBpbiBzZW5kaW5nIGFuZCByZWNlaXZpbmcgZGlyZWN0aW9ucyAoVDxzdWI+Uzwvc3Vi PiAmIzQzOyBUPHN1Yj5SPC9zdWI+KSBzaGFsbCBpbiBhbnkgY2FzZSBiZSDiiaQgMTkwbXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+T1BVUyDigJMgQU1SIHRyYW5zY29kaW5nIGFkZHMgYW4gYWRkaXRpb25hbCAyMTEuNSBtcyBp bXBsZW1lbnRhdGlvbi1hZ25vc3RpYyAoVDxzdWI+Uzwvc3ViPiAmIzQzOyBUPHN1Yj5SPC9zdWI+ KSBkZWxheSwgaW5jbHVkaW5nIDQwIG1zIGZvciBqaXR0ZXIgYnVmZmVyDQogYW5kIDQwIG1zIGZv ciBkaXNjb250aW51b3VzIHJlY2VwdGlvbiAoRFJYKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4z LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UbyBwdXQgdGhlc2UgbnVtYmVy cyBpbiBwZXJzcGVjdGl2ZSwgaXQgaXMgaW4gZ2VuZXJhbCBkZXNpcmFibGUgdG8gbWluaW1pemUg VUUgZGVsYXlzIHRvIGVuc3VyZSBsb3cgZW5vdWdoIGVuZC10by1lbmQgZGVsYXlzIGFuZCBoZW5j ZSBhIGdvb2QgY29udmVyc2F0aW9uYWwNCiBleHBlcmllbmNlLiZuYnNwOyBJbmNyZWFzaW5nIGRl bGF5IGNhdXNlcyBwZW9wbGUgdG8gZG91YmxlLXRhbGsgbWFraW5nIGNvbnZlcnNhdGlvbnMgaW5j cmVhc2luZ2x5IGZydXN0cmF0aW5nLiZuYnNwOyBHdWlkYW5jZSB0byBzdGF5IGJlbG93IDQwMCBt cyBtYXhpbXVtIG9uZS13YXkgZGVsYXkgaXMgZm91bmQgaW4gSVRVLVQgUmVjb21tZW5kYXRpb24g Ry4xMTQgYW5kIHRoZSBjb21wdXRhdGlvbmFsIEUtbW9kZWwgaXMgaW4gSVRVLVQgUmVjb21tZW5k YXRpb24gRy4xMDcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgYSBjb21wbGV4IHRvcGljIHdpdGggbWFueSBuZXR3 b3JrIGZhY3RvcnMgaW4gcGxheS4mbmJzcDsgTFRFIG9wZXJhdG9ycyBpbiAzR1BQIHNlZWsgVUUg ZGVsYXlzIChUPHN1Yj5TPC9zdWI+ICYjNDM7IFQ8c3ViPlI8L3N1Yj4pIGFyb3VuZCAxNTAgbXMu Jm5ic3A7IEFkZGluZyBPUFVTIOKAkw0KIEFNUiB0cmFuc2NvZGluZyBpbiB0aGUgbmV0d29yayBp bXBvc2VzIGFuIGFkZGl0aW9uYWwgMjExLjUgbXMgb24gdG9wIG9mIHRoYXQsIGp1c3QgZm9yIGF1 ZGlvLiZuYnNwOyBPcHRpb25hbGx5IHVzaW5nIEFNUiBpbiBXZWJSVEMsIHRob3NlIDIxMS41IG1z IGNhbiBiZSBlbGltaW5hdGVkLCBkZWxpdmVyaW5nIGEgc3VwZXJpb3IgZW5kLXVzZXIgZXhwZXJp ZW5jZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5DT05DTFVTSU9OOiAmbmJzcDtyZWdhcmRsZXNzIG9mIE1USSBj b2RlYyBjaG9pY2VzIGluIFdlYlJUQywgdG8gcHJvdmlkZSBhIGdvb2QgV2ViUlRDIOKAkyBMVEUg aW50ZXJvcCBleHBlcmllbmNlLCBlbWVyZ2luZyBXZWJSVEMgc3lzdGVtcyBtdXN0IGFjY29tbW9k YXRlIE1USSBjb2RlY3MNCiBhbHJlYWR5IGRlcGxveWVkIGluIHRoZSBMVEUgZG9tYWluIGFuZCBp biBtb2JpbGUgb3BlcmF0aW5nIHN5c3RlbXMsIG5hbWVseSBBTVIvQU1SLVdCIGFuZCBILjI2NC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UE9TSVRJT046Jm5ic3A7IFRvIGJlIGNsZWFyLCBzZXZlcmFsIEludGVsIFNvQ3MgbGF1 bmNoZWQgYXQgTVdDIHRoaXMgeWVhciBmb3Igc21hcnRwaG9uZXMgYW5kIHRhYmxldHMgc3VwcG9y dCBib3RoIFZQOCBhbmQgSC4yNjQgaGFyZHdhcmUgZW5jb2RlIGFuZCBkZWNvZGUg4oCTIHNvIElu dGVsDQogaXMgY29kZWMtbmV1dHJhbCBpbiB0aGlzIE1USSBkZWJhdGUuJm5ic3A7IEFkZGl0aW9u YWxseSwgSW50ZWwgaGFzIGhpZ2gtcGVyZm9ybWFuY2Ugc29sdXRpb25zIGZvciB0cmFuc2NvZGlu Zy4mbmJzcDsgSG93ZXZlciwgd2Ugd2lzaCB0byBpbmZvcm0gdGhlIGluZHVzdHJ5LCB3aXRoIHF1 YW50aXRhdGl2ZSBkYXRhLCBhYm91dCBpbXBhY3QgdG8gZW5kLXVzZXIgZXhwZXJpZW5jZSBvZiBt YW5kYXRpbmcgc3VjaCB0cmFuc2NvZGluZyBzbyBJRVRGIGNhbiBtYWtlIGENCiBkYXRhLWRyaXZl biBkZWNpc2lvbiBvbiB2aWRlbyBjb2RlY3MgYXMgd2VsbCBhcyByZWZsZWN0IG9uIHRoZSBpbXBh Y3Qgb2YgYWxyZWFkeSBoYXZpbmcgbWFuZGF0ZWQgdHJhbnNjb2Rpbmcgb24gdGhlIGF1ZGlvIHNp ZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXMgQ2F2aWdpb2xpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW50ZWwgQ29ycCwNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5TeXN0ZW0gQXJjaGl0ZWN0dXJlIGFuZCBQbGFu bmluZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4sIFZp ZGVvL011bHRpbWVkaWEsIE1vYmlsZSBhbmQgQ29tbXVuaWNhdGlvbnMgR3JvdXAgKE1DRyk8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsxICg0MTUpIDI1NC00NTQ1IG1vYmlsZTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mIzQzOzEgKDQwOCkgNjUzLTgzNDggZGVzazxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiYjNDM7MSAoNDA4KSA4ODQtMjQwMCBmYXg8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Z3JheSI+VGhp cyBlLW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFs IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4mbmJzcDsgQW55 IHJldmlldyBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu DQogSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3Qg dGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlcm5hcmQgQWJvYmE8YnI+DQo8Yj5TZW50OjwvYj4gU3Vu ZGF5LCBPY3RvYmVyIDE5LCAyMDE0IDI6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IEhhcmFsZCBBbHZl c3RyYW5kPGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtydGN3ZWJdIFBsYW4gZm9yIE1USSB2aWRlbyBjb2RlYz88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXJhbGQgc2FpZDombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkJlcm5hcmQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxicj4NCkkgdGhpbmsgdGhpcyBpcywgdG8gYSBsYXJnZSBkZWdyZWUsIGNvZGVj IGluZGVwZW5kZW50Ljxicj4NCjxicj4NCldlIGhhdmUgZGVtb25zdHJhdGVkIGludGVyb3BlcmFi aWxpdHkgb24gVlA4IGJldHdlZW4gRmlyZWZveCBhbmQgQ2hyb21lLCBhbmQgdXNhZ2Ugb2YgdmFy aW91cyBtZWNoYW5pc21zIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIHJlcGFpciBvZiBwYWNr ZXQgbG9zcyBiZWluZyBhcHBsaWVkIGluIGxpdmUgc2VydmljZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlNvIGl0IGNhbid0IGJlIGFsbCBiYWQuLi4uLjwvc3Bhbj4mcXVvdDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JBXSAmbmJzcDtJIGFn cmVlIHRoYXQgdGhlIGxhY2sgb2YgaW50ZXJvcGVyYWJpbGl0eSBpcyBsYXJnZWx5ICZxdW90O2Nv ZGVjIGluZGVwZW5kZW50JnF1b3Q7OiAmbmJzcDsgdGhhdCBpcywgaW1wbGVtZW50YXRpb25zIGJh c2VkIG9uIGRpZmZlcmVudCBtZWNoYW5pc21zIGZvciBjb25nZXN0aW9uIGNvbnRyb2wsIHJlcGFp ciwgZXRjLiB3aWxsIGV4aGliaXQgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcywgcmVnYXJkbGVz cyBvZiB0aGUgY29kZWMNCiBjaG9zZW4uICZuYnNwOyBUaGUgcmVhbCB0ZXN0IGZvciBSVENXRUIg d2lsbCBiZSB0byBtb3ZlIGJleW9uZCAmcXVvdDtpbnRlcm9wZXJhYmlsaXR5IG9mIGltcGxlbWVu dGF0aW9ucyBzaGFyaW5nIHNvdXJjZSBjb2RlJnF1b3Q7ICZuYnNwO3RvICZxdW90O2ludGVyb3Bl cmFiaWxpdHkgb2YgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zLCBiYXNlZCBvbiBvcGVuIHN0 YW5kYXJkcyZxdW90Oy4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgT2N0IDE5LCAyMDE0IGF0IDE6MzggUE0s IEhhcmFsZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQu bm8iIHRhcmdldD0iX2JsYW5rIj5oYXJhbGRAYWx2ZXN0cmFuZC5ubzwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMC8x OS8yMDE0IDA1OjQzIFBNLCBCZXJuYXJkIEFib2JhIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtBbmQgaXRzIG9uZSBvZiB0 aGUgaXNzdWVzIGhvbGRpbmcgdXAgd2lkZXIgYWRvcHRpb24gb2YgdGhlIHRlY2hub2xvZ3kmcXVv dDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JBXSBT cGVjaWZ5aW5nIGFuIE1USSBlbmNvZGVyL2RlY29kZXIgaXMgbm90IHN1ZmZpY2llbnQgZm9yIGlu dGVyb3BlcmFiaWxpdHkuJm5ic3A7IEl0IGlzIGFsc28gbmVjZXNzYXJ5IHRvIHNwZWNpZnkgdGhl IHRyYW5zcG9ydCBpbiBlbm91Z2ggZGV0YWlsIHRvIGFsbG93IGluZGVwZW5kZW50IGltcGxlbWVu dGF0aW9ucyB0aGF0IGludGVyb3BlcmF0ZSB3ZWxsIGVub3VnaCB0byBiZSB1c2FibGUgaW4gYSB3 aWRlIHZhcmlldHkNCiBvZiBzY2VuYXJpb3MsIGluY2x1ZGluZyB3aXJlbGVzcyBuZXR3b3JrcyB3 aGVyZSBsb3NzIGlzIGNvbW1vbmx5IGV4cGVyaWVuY2VkLiZuYnNwOyA8bzpwPg0KPC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCkJlcm5hcmQsPGJyPg0KPGJyPg0KSSB0aGluayB0aGlzIGlzLCB0byBhIGxhcmdlIGRlZ3Jl ZSwgY29kZWMgaW5kZXBlbmRlbnQuPGJyPg0KPGJyPg0KV2UgaGF2ZSBkZW1vbnN0cmF0ZWQgaW50 ZXJvcGVyYWJpbGl0eSBvbiBWUDggYmV0d2VlbiBGaXJlZm94IGFuZCBDaHJvbWUsIGFuZCB1c2Fn ZSBvZiB2YXJpb3VzIG1lY2hhbmlzbXMgZm9yIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgcmVwYWly IG9mIHBhY2tldCBsb3NzIGJlaW5nIGFwcGxpZWQgaW4gbGl2ZSBzZXJ2aWNlcy48YnI+DQo8YnI+ DQpTbyBpdCBjYW4ndCBiZSBhbGwgYmFkLi4uLi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgbWFkZSB0aGUgbWlzdGFr ZSBvZiBoYXZpbmcgYW4gTVRJIGRpc2N1c3Npb24gcHJldmlvdXNseSB3aXRoIG5vdCBlbm91Z2gg ZGV0YWlscyBvbiB0aGF0IHN1YmplY3QsIHBhcnRpY3VsYXJseSB3aXRoIHJlc3BlY3QgdG8gSC4y NjQuIGRyYWZ0LWlldGYtcnRjd2ViLXZpZGVvIHNlY3Rpb25zIDQuMiAtIDQuNCByZW1haW4gc2tl dGNoeSBhdCBiZXN0LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U28gaWYgd2UgYXJlIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24gYWdh aW4sIGl0IHNob3VsZCBvY2N1ciBpbiB0aGUgY29udGV4dCBvZiBkZXRhaWxlZCBzcGVjaWZpY2F0 aW9ucyBhbmQgaW50ZXJvcGVyYWJpbGl0eSByZXBvcnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgT2N0IDE5LCAy MDE0IGF0IDg6MTQgQU0sIEpvbmF0aGFuIFJvc2VuYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpk cm9zZW5AamRyb3Nlbi5uZXQiIHRhcmdldD0iX2JsYW5rIj5qZHJvc2VuQGpkcm9zZW4ubmV0PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSdtIGluIGZhdm9yIG9mIHRha2luZyBhbm90aGVyIHJ1biBhdCB0aGlzLiA8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB3b3JraW5nIGdyb3VwIGhhcyBy ZXBlYXRlZGx5IHNhaWQgdGhhdCBhbiBNVEkgY29kZWMgaXMgc29tZXRoaW5nIHdlIG5lZWQgdG8g cHJvZHVjZS4gQW5kIGl0cyBvbmUgb2YgdGhlIGlzc3VlcyBob2xkaW5nIHVwIHdpZGVyIGFkb3B0 aW9uIG9mIHRoZSB0ZWNobm9sb2d5IChub3QgdGhlIG9ubHkgb25lIGZvciBzdXJlKS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIHRoaW5n cyBoYXZlIGNoYW5nZWQgc2luY2UgdGhlIGxhc3QgbWVldGluZywgYSB5ZWFyIGFnbyBub3cgKE5v dmVtYmVyIGluIFZhbmNvdXZlcikuIENpc2NvJ3Mgb3BlbjI2NCBwbHVnaW4gc2hpcHBlZCBhbmQg bm93IGp1c3QgcmVjZW50bHkgaXMgaW50ZWdyYXRlZCBpbnRvIEZpcmVmb3guIGlPUzggc2hpcHBl ZCB3aXRoIEFQSXMgZm9yIEgyNjQuIFRoZXJlIGFyZSBvdGhlciB0aGluZ3Mgd29ydGggbm90aW5n Lg0KIFdpbGwgdGhpcyBjaGFuZ2UgdGhlIG1pbmRzIG9mIGV2ZXJ5b25lPyBTdXJlbHkgbm90LiBX aWxsIGl0IHN3YXkgZW5vdWdoIGZvciB1cyB0byBhY2hpZXZlIHJvdWdoIGNvbnNlbnN1cz8gTWF5 YmUuIElNSE8gLSB3b3J0aCBmaW5kaW5nIG91dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIE9jdCAxOCwg MjAxNCBhdCA1OjA4IFBNLCBBbGV4YW5kcmUgR09VQUlMTEFSRCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFnb3VhaWxsYXJkQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFnb3VhaWxsYXJkQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiYjNDM7MSB0byBub3QgaGF2aW5nIE1USSBjb2RlYyBkaXNjdXNzaW9uIHVubGVzcyBz b21lIHByb2dyZXNzIGhhcyBiZWVuIG1hZGUgb24gVlA4IGF0IE1QRUcuJm5ic3A7QW55IG5ld3Mg b24gdGhhdD8gSSdtIHNoYXJpbmcgaGFyYWxkJ3MgJm5ic3A7ZmVlbGluZyB0aGF0IHRoZXJlIHdh cyBubyBjaGFuZ2Ugb24gdGhlIG1lbWJlcnMgcG9zaXRpb24uJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0 IDE3LCAyMDE0IGF0IDk6MjIgUE0sIEhhcmFsZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWls dG86aGFyYWxkQGFsdmVzdHJhbmQubm8iIHRhcmdldD0iX2JsYW5rIj5oYXJhbGRAYWx2ZXN0cmFu ZC5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gMTAvMTcvMjAxNCAxMjowMiBBTSwgQmVybmFyZCBBYm9iYSB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSB0aGluZyB3ZSBjb3VsZCBkbyBpbnN0ZWFkIG9m IHdhc3RpbmcgdGltZSBvbiBNVEkgaXMgdG8gYWN0dWFsbHkgbWFrZSBwcm9ncmVzcyBvbiBTZWN0 aW9ucyA0LjIgLSA0LjQgb2YgZHJhZnQtSUVURi1SVENXRUItdmlkZW8sIHNvIHdlIGNvdWxkIGFj dHVhbGx5IGludGVyb3BlcmF0ZSByZWdhcmRsZXNzIG9mIHRoZSBjb2RlYy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBiaWcgYXJndW1lbnQgZm9yIGFuIE1U SSBpcyBhY3R1YWxseSB0aGUgb25lIHN0YXRlZCBpbiAtb3ZlcnZpZXc6IEl0IGd1YXJkcyBhZ2Fp bnN0IGludGVyb3BlcmFiaWxpdHkgZmFpbHVyZS48YnI+DQo8YnI+DQpJIHdvdWxkIGxpa2UgdG8g aGF2ZSBhbiBlY29zeXN0ZW0gd2hlcmUgb25lIGNhbiBmaWVsZCBhIGJveCwgY29ubmVjdCBpdCB0 byBldmVyeXRoaW5nIGVsc2UsIGFuZCBydW4gd2VsbCBmb3IgKnNvbWUqIGxldmVsIG9mICZxdW90 O3dlbGwmcXVvdDsgLSBhbmQgSSB3b3VsZCBwcmVmZXIgdGhhdCBlY29zeXN0ZW0gdG8gYmUgb25l IHdoZXJlIGl0J3MgcG9zc2libGUgdG8gZmllbGQgdGhlIGJveCB3aXRob3V0IG1ha2luZyBwcmlv ciBhcnJhbmdlbWVudHMgd2l0aCBhbnlvbmUNCiBhYm91dCBsaWNlbnNlcy48YnI+DQo8YnI+DQpU aGlzIGFyZ3VtZW50IGhhc24ndCBjaGFuZ2VkIG9uZSB3aGl0IHNpbmNlIGxhc3QgdGltZSB3ZSBk aXNjdXNzZWQgaXQuIEFuZCBJIGRvbid0IHNlZSBtdWNoIG1vdmVtZW50IG9uIHRoZSBzcGVjaWZp Y3Mgb2YgdGhlIHByb3Bvc2FscyBlaXRoZXIuPGJyPg0KPGJyPg0KV2UnbGwgaGF2ZSB0byBpbnRl cm9wZXJhdGUgd2VsbCB3aXRoIHRoZSBjb2RlY3Mgd2UgZmllbGQuIFNvIHVzaW5nIHNvbWUgdGlt ZSB0byBkaXNjdXNzIGRyYWZ0LWlldGYtcnRjd2ViLXZpZGVvIHNlZW1zIHRvIG1ha2Ugc2Vuc2Uu IChBbmQgNC4xIGlzbid0IGZpbmlzaGVkIGVpdGhlci4gVGhlcmUncyBvbmUgc2VudGVuY2UgdGhh dCBuZWVkcyB0byBiZSByZW1vdmVkLik8YnI+DQo8YnI+DQpJIHdvdWxkbid0IHNheSBJJ2QgYmUg aGFwcHkgdG8gbm90IGRpc2N1c3MgdGhpcyBpbiBIb25vbHVsdS4gQnV0IEknZCBwcmVmZXIgdG8g cmUtZGlzY3VzcyBiYXNlZCBvbiB0aGUga25vd2xlZGdlIHRoYXQgc29tZSBzaWduaWZpY2FudCBw bGF5ZXJzIGhhdmUgYWN0dWFsbHkgY2hhbmdlZCB0aGVpciBtaW5kcy48YnI+DQo8YnI+DQpBdCB0 aGUgbW9tZW50LCBJIGRvbid0IHNlZSBzaWducyB0aGF0IGFueSBvZiB0aGUgcG9sbCByZXNwb25k ZW50cyBoYXZlIHNhaWQgJnF1b3Q7SSBoYXZlIGNoYW5nZWQgbXkgbWluZCZxdW90Oy48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KSGFyYWxkPC9zcGFuPiA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pk9uIE9jdCAxNiwgMjAxNCwgYXQgMjoyOCBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9 Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDE2IE9jdG9iZXIgMjAxNCAxNDoxNywgTWF0dGhldyBLYXVmbWFuICZs dDs8YSBocmVmPSJtYWlsdG86bWF0dGhld0BtYXR0aGV3LmF0IiB0YXJnZXQ9Il9ibGFuayI+bWF0 dGhld0BtYXR0aGV3LmF0PC9hPiZndDsgd3JvdGU6PGJyPg0KQW5kIHRoYXQncyBiZWNhdXNlIHNv bWV0aGluZyBzdWJzdGFudGl2ZSBoYXMgY2hhbmdlZCwgb3Igc2ltcGx5IGJlY2F1c2U8YnI+DQp3 YXN0aW5nIHRoZSBXRyB0aW1lIG9uIHRoaXMgYWdhaW4gaXMgbW9yZSBlbnRlcnRhaW5pbmcgdGhh biBhY3R1YWxseTxicj4NCmZpbmlzaGluZyBhIHNwZWNpZmljYXRpb24gdGhhdCBjYW4gYmUgaW5k ZXBlbmRlbnRseSBpbXBsZW1lbnRlZCBieSBhbGw8YnI+DQpicm93c2VyIHZlbmRvcnM/IChBIHNw ZWNpZmljYXRpb24gdGhhdCB3ZSBhcmUgbm93aGVyZSBuZWFyIGhhdmluZywgYXMgZmFyIGFzPGJy Pg0KSSBjYW4gdGVsbCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcnNv bmFsbHksIEkndmUgZm91bmQgdGhlIHJlcHJpZXZlIGZyb20gdGhpcyBmaWdodCByZWZyZXNoaW5n LiZuYnNwOyBBbmQ8YnI+DQppdCB3b3VsZCBhcHBlYXIgdGhhdCB3ZSd2ZSBtYWRlIHNvbWUgcmVh bCBwcm9ncmVzcyBhcyBhIHJlc3VsdC4mbmJzcDsgSSdkPGJyPg0Kc3VnZ2VzdCB0aGF0IGlmIHdl IGRvbid0IGhhdmUgbmV3IGluZm9ybWF0aW9uLCB3ZSBjb250aW51ZSB0byBzcGVuZDxicj4NCm91 ciB0aW1lIHByb2R1Y3RpdmVseS4mbmJzcDsgSWYgd2UgY2FuJ3QgZmluZCB0b3BpY3MgdG8gb2Nj dXB5IG91ciBtZWV0aW5nPGJyPg0KYWdlbmRhIHRpbWUsIHRoZW4gbWF5YmUgd2UgY2FuIGZyZWUg YW4gYWdlbmRhIHNsb3QuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl YiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5BbGV4LiBHb3VhaWxsYXJkLCBQaEQs IFBoRCwgTUJBIDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Q1RPIC0gVGVtYXN5cyBDb21tdW5p Y2F0aW9ucywgUydwb3JlIC8gTW91bnRhaW4gVmlldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4 ODg4Ij5QcmVzaWRlbnQgLSBDb1NNbyBTb2Z0d2FyZSwgQ2FtYnJpZGdlLCBNQTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+PGEgaHJlZj0iaHR0cDovL3NnLmxpbmtlZGluLmNvbS9hZ291 YWlsbGFyZCIgdGFyZ2V0PSJfYmxhbmsiPnNnLmxpbmtlZGluLmNvbS9hZ291YWlsbGFyZDwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50Oi0uMjVpbjtsaW5lLWhlaWdodDox NC40cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7dmVydGljYWwtYWxpZ246YmFzZWxpbmUiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sO2NvbG9yOiMzMzMzMzMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OmluaGVyaXQ7Y29sb3I6IzMzMzMzMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Sm9uYXRoYW4gUm9zZW5iZXJnLCBQaC5ELjxicj4NCjxhIGhyZWY9Im1h aWx0bzpqZHJvc2VuQGpkcm9zZW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+amRyb3NlbkBqZHJvc2Vu Lm5ldDwvYT48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3Lmpkcm9zZW4ubmV0IiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL3d3dy5qZHJvc2VuLm5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+cnRjd2ViIG1h aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlN1cnZlaWxs YW5jZSBpcyBwZXJ2YXNpdmUuIEdvIERhcmsuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpy dGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+ cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD2339941A25XMB122CNCrimnet_-- From nobody Mon Oct 20 08:00:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571BC1A901F for ; Mon, 20 Oct 2014 08:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVDKEw5mup9Z for ; Mon, 20 Oct 2014 08:00:38 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F981A890E for ; Mon, 20 Oct 2014 07:35:09 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id BCCD078BE3596; Mon, 20 Oct 2014 14:35:04 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9KEYwSG014453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 16:34:58 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 16:34:58 +0200 From: "DRAGE, Keith (Keith)" To: Andrew Allen , "chris.cavigioli@intel.com" , "harald@alvestrand.no" , "bernard.aboba@gmail.com" Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP7G0L2AshmHfxg0SddD4axlD+Cpw5C5ZQ Date: Mon, 20 Oct 2014 14:34:58 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B2627F1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B2627F1FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1hegRSdrUSJShNA5XXQG8Ux36ZI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 15:00:46 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B2627F1FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable The scenario where you might want to transcode the audio codec is where you= have wideband audio in both the OPUS and the AMR, and you believe by trans= coding you can achieve a wideband quality, rather than falling back to G.71= 1. And for interworking between 3GPP devices that are not using webRTC, the= audio will still be AMR or AMR-WB or EVC, not OPUS. But audio transcoding is not particularly a concern for me. It is trying wh= ere possible to avoid video transcoding. Keith ________________________________ From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 20 October 2014 14:52 To: chris.cavigioli@intel.com; harald@alvestrand.no; bernard.aboba@gmail.co= m Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? Chris What is the scenario that dictates the need for direct transcoding between = OPUS and AMR? All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE devi= ces OPUS can be negotiated with non mobile RTCweb devices end to end. My expectation is that for mobile devices the RTCweb client will also have = access to the embedded AMR codec so mobile RTCweb devices can interoperate = using AMR with non-RTCweb enabled mobile IMS devices that support AMR. For interoperation between non mobile RTCweb devices and mobile non RTCweb = IMS devices the non mobile RTCweb device can use G.711 to the transcoder fo= r transcoding to AMR on the other side. While not ideal this will be no wor= se than non mobile RTCweb devices interoperating with circuit switched only= mobile devices which will be forced to interoperate via the PSTN. As RTCweb becomes universal on mobile devices I expect that support for OPU= S will become native and mobile IMS devices will also be able to use OPUS e= ven when operating without the use of the browser (i.e. in non RTCweb mode)= for better interoperation with non-mobile RTCweb devices. The lifetime of most mobile devices is 2 years or less so this is likely to= be mainly a short term transition issue only. Andrew From: Cavigioli, Chris [mailto:chris.cavigioli@intel.com] Sent: Sunday, October 19, 2014 09:20 PM Eastern Standard Time To: Harald Alvestrand ; Bernard Aboba Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? Harald said: "We made the mistake of having an MTI discussion previously with not enough= details on that subject..." We didn't have quantitative data earlier for a data-driven decision. Futur= e Web - LTE interop is important. A group of us in GSMA have been looking = at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video= /messaging), specifically looking at user experience impact of latency intr= oduced by added in-network transcoding. GSMA has approved the whitepaper a= nd it is being prepared for public distribution. WebRTC - LTE transcoding is now MANDATORY because of "WebRTC Audio Codec an= d Processing Requirements". http://tools.ietf.org/html/draft-ietf-rtcweb-au= dio-05, where MTI audio codecs in WebRTC and in LTE are dissimilar. Thus, = REGARDLESS of the video codecs, there is already a significant degradation = imposed on Web - LTE links if only MTI codecs are used. The only systems t= o avoid this are those which implement OPTIONAL audio codecs to be transcod= er-free with LTE. The same can apply for video codecs. The GSMA whitepaper refers to: 1. Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by 3= GPP SA4 in August 2014. To paraphrase, performance objectives for maximum = VoLTE device delays in error and jitter free conditions and AMR speech code= c operation, the sum of the UE delays in sending and receiving directions (= TS + TR) should be =98 150ms. If this performance objective cannot be met, = the sum of the UE delays in sending and receiving directions (TS + TR) shal= l in any case be =98 190ms. 2. OPUS - AMR transcoding adds an additional 211.5 ms implementation-ag= nostic (TS + TR) delay, including 40 ms for jitter buffer and 40 ms for dis= continuous reception (DRX). 3. To put these numbers in perspective, it is in general desirable to m= inimize UE delays to ensure low enough end-to-end delays and hence a good c= onversational experience. Increasing delay causes people to double-talk ma= king conversations increasingly frustrating. Guidance to stay below 400 ms= maximum one-way delay is found in ITU-T Recommendation G.114 and the compu= tational E-model is in ITU-T Recommendation G.107. This is a complex topic with many network factors in play. LTE operators i= n 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS - AMR transcodi= ng in the network imposes an additional 211.5 ms on top of that, just for a= udio. Optionally using AMR in WebRTC, those 211.5 ms can be eliminated, de= livering a superior end-user experience. CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a good W= ebRTC - LTE interop experience, emerging WebRTC systems must accommodate MT= I codecs already deployed in the LTE domain and in mobile operating systems= , namely AMR/AMR-WB and H.264. POSITION: To be clear, several Intel SoCs launched at MWC this year for sm= artphones and tablets support both VP8 and H.264 hardware encode and decode= - so Intel is codec-neutral in this MTI debate. Additionally, Intel has h= igh-performance solutions for transcoding. However, we wish to inform the = industry, with quantitative data, about impact to end-user experience of ma= ndating such transcoding so IETF can make a data-driven decision on video c= odecs as well as reflect on the impact of already having mandated transcodi= ng on the audio side. Chris Cavigioli Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and = Communications Group (MCG) +1 (415) 254-4545 mobile +1 (408) 653-8348 desk +1 (408) 884-2400 fax This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient(s). Any review or distribution by others is s= trictly prohibited. If you are not the intended recipient, please contact t= he sender and delete all copies. From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Sunday, October 19, 2014 2:29 PM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? Harald said: "Bernard, I think this is, to a large degree, codec independent. We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services. So it can't be all bad....." [BA] I agree that the lack of interoperability is largely "codec independe= nt": that is, implementations based on different mechanisms for congestio= n control, repair, etc. will exhibit interoperability problems, regardless = of the codec chosen. The real test for RTCWEB will be to move beyond "int= eroperability of implementations sharing source code" to "interoperability= of independent implementations, based on open standards". On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand > wrote: On 10/19/2014 05:43 PM, Bernard Aboba wrote: "And its one of the issues holding up wider adoption of the technology" [BA] Specifying an MTI encoder/decoder is not sufficient for interoperabili= ty. It is also necessary to specify the transport in enough detail to allo= w independent implementations that interoperate well enough to be usable in= a wide variety of scenarios, including wireless networks where loss is com= monly experienced. Bernard, I think this is, to a large degree, codec independent. We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services. So it can't be all bad..... We made the mistake of having an MTI discussion previously with not enough = details on that subject, particularly with respect to H.264. draft-ietf-rtc= web-video sections 4.2 - 4.4 remain sketchy at best. So if we are to have the discussion again, it should occur in the context o= f detailed specifications and interoperability reports. On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: I'm in favor of taking another run at this. The working group has repeatedly said that an MTI codec is something we nee= d to produce. And its one of the issues holding up wider adoption of the te= chnology (not the only one for sure). And things have changed since the last meeting, a year ago now (November in= Vancouver). Cisco's open264 plugin shipped and now just recently is integr= ated into Firefox. iOS8 shipped with APIs for H264. There are other things = worth noting. Will this change the minds of everyone? Surely not. Will it s= way enough for us to achieve rough consensus? Maybe. IMHO - worth finding o= ut. On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD > wrote: +1 to not having MTI codec discussion unless some progress has been made on= VP8 at MPEG. Any news on that? I'm sharing harald's feeling that there wa= s no change on the members position. On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: On 10/17/2014 12:02 AM, Bernard Aboba wrote: One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec. The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure. I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I would pref= er that ecosystem to be one where it's possible to field the box without ma= king prior arrangements with anyone about licenses. This argument hasn't changed one whit since last time we discussed it. And = I don't see much movement on the specifics of the proposals either. We'll have to interoperate well with the codecs we field. So using some tim= e to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't fi= nished either. There's one sentence that needs to be removed.) I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer= to re-discuss based on the knowledge that some significant players have ac= tually changed their minds. At the moment, I don't see signs that any of the poll respondents have said= "I have changed my mind". Harald On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: On 16 October 2014 14:17, Matthew Kaufman > wrote: And that's because something substantive has changed, or simply because wasting the WG time on this again is more entertaining than actually finishing a specification that can be independently implemented by all browser vendors? (A specification that we are nowhere near having, as far a= s I can tell) Personally, I've found the reprieve from this fight refreshing. And it would appear that we've made some real progress as a result. I'd suggest that if we don't have new information, we continue to spend our time productively. If we can't find topics to occupy our meeting agenda time, then maybe we can free an agenda slot. _______________________________________________ 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 -- Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard =9E _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net _______________________________________________ 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 -- Surveillance is pervasive. Go Dark. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_949EF20990823C4C85C18D59AA11AD8B2627F1FR712WXCHMBA11zeu_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
The scenario where you might want= to transcode the audio codec is where you have wideband audio in both the = OPUS and the AMR, and you believe by transcoding you can achieve a wideband quality, rather than falling back to G.711. And= for interworking between 3GPP devices that are not using webRTC, the audio= will still be AMR or AMR-WB or EVC, not OPUS.
 
But audio transcoding is not part= icularly a concern for me. It is trying where possible to avoid video trans= coding.
 
Keith

From: rtcweb [mailto:rtcweb-bounces= @ietf.org] On Behalf Of Andrew Allen
Sent: 20 October 2014 14:52
To: chris.cavigioli@intel.com; harald@alvestrand.no; bernard.aboba@g= mail.com
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan for MTI video codec?


Chris

What is the scenario that dictates the need for direct transcoding between = OPUS and AMR?

All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE devi= ces OPUS can be negotiated with non mobile RTCweb devices end to end.

My expectation is that for mobile devices the RTCweb client will also have = access to the embedded AMR codec so mobile RTCweb devices can interoperate = using AMR with non-RTCweb enabled mobile IMS devices that support AMR.

For interoperation between non mobile RTCweb devices and mobile non RTCweb = IMS devices the non mobile RTCweb device can use G.711 to the transcoder fo= r transcoding to AMR on the other side. While not ideal this will be no wor= se than non mobile RTCweb devices interoperating with circuit switched only mobile devices which will be for= ced to interoperate via the PSTN.

As RTCweb becomes universal on mobile devices I expect that support for OPU= S will become native and mobile IMS devices will also be able to use OPUS e= ven when operating without the use of the browser (i.e. in non RTCweb mode)= for better interoperation with non-mobile RTCweb devices.

The lifetime of most mobile devices is 2 years or less so this is likely to= be mainly a short term transition issue only.

Andrew
 
From= : Cavigioli, Chris [mailto:chris.cavigioli@intel.com]
Sent: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
To: Harald Alvestrand <harald@alvestrand.no>; Bernard Aboba &l= t;bernard.aboba@gmail.com>
Cc: rtcweb@ietf.org <rtcweb@ietf.org>
Subject: Re: [rtcweb] Plan for MTI video codec?
 

Harald said: 

“We made the mistake of having an MTI discussi= on previously with not enough details on that subject…”=

 

We didn’t have quantitative data earli= er for a data-driven decision.  Future Web – LTE interop is impo= rtant.  A group of us in GSMA have been looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messagin= g), specifically looking at user experience impact of latency introduced by= added in-network transcoding.  GSMA has approved the whitepaper and i= t is being prepared for public distribution. 

 

WebRTC – LTE transcoding is now MANDAT= ORY because of “WebRTC Audio Codec and Processing Requirements”= . http://to= ols.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio codecs in= WebRTC and in LTE are dissimilar.  Thus, REGARDLESS of the video code= cs, there is already a significant degradation imposed on Web – LTE links if only MTI codecs are used.  The on= ly systems to avoid this are those which implement OPTIONAL audio codecs to= be transcoder-free with LTE.  The same can apply for video codecs.

 

The GSMA whitepaper refers to:

1.     Quantitative voice-over-LTE (VoLTE) = delay limits were agreed-to by 3GPP SA4 in August 2014.  To paraphrase= , performance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec ope= ration, the sum of the UE delays in sending and receiving directions (TS + TR) should be =98 150ms. If this performance obje= ctive cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR) shall in any case be =98 190ms.

2.     OPUS – AMR transcoding adds an= additional 211.5 ms implementation-agnostic (TS + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.     To put these numbers in perspective,= it is in general desirable to minimize UE delays to ensure low enough end-= to-end delays and hence a good conversational experience.  Increasing delay causes people to double-talk making con= versations increasingly frustrating.  Guidance to stay below 400 ms ma= ximum one-way delay is found in ITU-T Recommendation G.114 and the computat= ional E-model is in ITU-T Recommendation G.107.

 

This is a complex topic with many network fa= ctors in play.  LTE operators in 3GPP seek UE delays (TS &#= 43; TR) around 150 ms.  Adding OPUS – AMR transcoding in the network imposes an additional 211.5 ms on t= op of that, just for audio.  Optionally using AMR in WebRTC, those 211= .5 ms can be eliminated, delivering a superior end-user experience. 

 

CONCLUSION:  regardless of MTI codec ch= oices in WebRTC, to provide a good WebRTC – LTE interop experience, e= merging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely= AMR/AMR-WB and H.264.

 

POSITION:  To be clear, several Intel S= oCs launched at MWC this year for smartphones and tablets support both VP8 = and H.264 hardware encode and decode – so Intel is codec-neutral in this MTI debate.  Additionally, Intel has h= igh-performance solutions for transcoding.  However, we wish to inform= the industry, with quantitative data, about impact to end-user experience = of mandating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impa= ct of already having mandated transcoding on the audio side.

 

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Mul= timedia, Mobile and Communications Group (MCG)

+1 (415) 254-4545 mobile

+1 (408) 653-8348 desk

+1 (408) 884-2400 fax

This e-mail may contain confidential and pri= vileged material for the sole use of the intended recipient(s).  Any r= eview or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the send= er and delete all copies.

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan for MTI video codec?

 

Harald said: 

 

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad....."

 

[BA]  I agree that the lack of interoperability= is largely "codec independent":   that is, implementations = based on different mechanisms for congestion control, repair, etc. will exh= ibit interoperability problems, regardless of the codec chosen.   The real test for RTCWEB will be to move beyond "inter= operability of implementations sharing source code"  to "int= eroperability of independent implementations, based on open standards"= .   

 

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:

"And its one of the issues holding up wider ado= ption of the technology"

 

[BA] Specifying an MTI encoder/decoder is not suffic= ient for interoperability.  It is also necessary to specify the transp= ort in enough detail to allow independent implementations that interoperate= well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienc= ed. 


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....




 

We made the mistake of having an MTI discussion prev= iously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.=  

 

So if we are to have the discussion again, it should= occur in the context of detailed specifications and interoperability repor= ts.

 

 

 

 

 

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrose= n.net> wrote:

I'm in favor of taking another run at this.

 

The working group has repeatedly said that an MTI co= dec is something we need to produce. And its one of the issues holding up w= ider adoption of the technology (not the only one for sure).

 

And things have changed since the last meeting, a ye= ar ago now (November in Vancouver). Cisco's open264 plugin shipped and now = just recently is integrated into Firefox. iOS8 shipped with APIs for H264. = There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough fo= r us to achieve rough consensus? Maybe. IMHO - worth finding out.

 

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLAR= D <agouaillar= d@gmail.com> wrote:

+1 to not having MTI codec discussion unless som= e progress has been made on VP8 at MPEG. Any news on that? I'm sharing= harald's  feeling that there was no change on the members position.&n= bsp;

 

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:

One thing we could do instead of wasting time on MTI= is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-vi= deo, so we could actually interoperate regardless of the codec.<= /p>


The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the box = without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. And = I don't see much movement on the specifics of the proposals either.

We'll have to interoperate well with the codecs we field. So using some tim= e to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't fi= nished either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer= to re-discuss based on the knowledge that some significant players have ac= tually changed their minds.

At the moment, I don't see signs that any of the poll respondents have said= "I have changed my mind".

Harald





On Oct 16, 2014, at 2:= 28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at>= ; wrote:
And that's because something substantive has changed, or simply because
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)

Personally, I've found the reprieve from this fight = refreshing.  And
it would appear that we've made some real progress as a result.  I'd suggest that if we don't have new information, we continue to spend
our time productively.  If we can't find topics to occupy our meeting<= br> agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



 

-- =

Alex. Gouaillard, PhD= , PhD, MBA

---------------------= ---------------------------------------------------------------<= /span>

CTO - Temasys Communi= cations, S'pore / Mountain View

President - CoSMo Sof= tware, Cambridge, MA

---------------------= ---------------------------------------------------------------<= /span>

=9E          


_______________________________________________
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

 

-- 
Surveillance is pervasive. Go Dark.


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

 

--_000_949EF20990823C4C85C18D59AA11AD8B2627F1FR712WXCHMBA11zeu_-- From nobody Mon Oct 20 11:55:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479D71A90D5 for ; Mon, 20 Oct 2014 11:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSgNNshcMn1p for ; Mon, 20 Oct 2014 11:55:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D9C1A90D7 for ; Mon, 20 Oct 2014 11:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1413831338; x=1415040938; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J3A9/6wTrESAn/X9Py/swD3/mHU/rfe9ziLhpRtZtqo=; b=guTMLtM70aea9allQbhRUx7F16gkcBFtBt+pasWRLUyApFpm9tTh3s6B 070od5TDt8b8ag/N7S8jNBofZrKL6KNqYDtoiwOjpDaDL4slbsgKDgNgH XcEClZicW7F2zx7M+HIQGyPZluGn5h4uXV6DeVu6iLYF9iff6ucK+/8hC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAG1ZRVStJA2F/2dsb2JhbABcgmsjU1gEzCMKhnlUAoETFgF9hAIBAQEDAQEBATc0CwULAgEIGB4QJwslAgQOBYg3BwEBDMU1AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQHjMHgy2BHgWFFYxshEaHE5Yig3dsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,757,1406592000"; d="scan'208";a="364645935" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP; 20 Oct 2014 18:55:37 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9KItaGu029522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 18:55:36 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 13:55:36 -0500 From: "Cullen Jennings (fluffy)" To: Peter Saint-Andre - &yet Thread-Topic: [rtcweb] Agenda for the upcoming meeting Thread-Index: AQHP6WQkELuqOHwpNkKkJQp4VRk4Xpw4SxAAgAFk34A= Date: Mon, 20 Oct 2014 18:55:36 +0000 Message-ID: <3A26E75E-BEF0-4D71-9372-01CE9D199E3D@cisco.com> References: <54442F52.3090608@andyet.net> In-Reply-To: <54442F52.3090608@andyet.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.210] Content-Type: text/plain; charset="us-ascii" Content-ID: <0F4DE9B87218E248994EB145EC6ABAB3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CzUKRYluMupvrU0EhEl9xoM86Xo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 18:55:39 -0000 So lets be clear here. Every time we checked, there has been consensus that= we need an MTI codec. So right now this work is sort of blocked on that an= d we would like to get what people are calling webrtc 1.0 out before the en= d of 2015. I think that a pragmatic look at this would result there is at = least some reasonable odds it might take more than one or two meetings to r= esolve this if we end up in an alternative consensus process.=20 You said on the list you felt "the state of video codec development needs t= o evolve" before this discussions. I did not know what you what you see nee= ds to happen in this evolution and how long should we wait before on this. = I was wondering if you meant we should wait for the IETF to standardize a v= ideo codec (like the netvc BOF is proposing) but I really had no idea what = you meant=20 Do you think there would be a better time to discuss this? Cullen So far much of conversation has been folks in the Microsoft camp - keep in = mind some of that group has said in the past they would be=20 On Oct 19, 2014, at 3:38 PM, Peter Saint-Andre - &yet wr= ote: > On 10/16/14, 11:10 AM, Ted Hardie wrote: >> During this morning chairs call, we discussed the agenda for the >> upcoming meeting. The two big items are JSEP and the video codec >> discussion, and our current thought is to have the JSEP discussion on >> Monday and the video codec discussion on Thursday. >=20 > As far as I can see, the temper of the list has been that it would be pre= mature and a waste of energy to discuss the video codec topic at IETF 91. D= o the chairs see things differently? >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://andyet.com/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Oct 20 12:28:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCD01AC406 for ; Mon, 20 Oct 2014 12:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-Qr0rHKJtqq for ; Mon, 20 Oct 2014 12:28:25 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C753D1AC3FF for ; Mon, 20 Oct 2014 12:28:23 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id at20so63258iec.39 for ; Mon, 20 Oct 2014 12:28:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MF0KmWG8N2i581mjvUR+Fkx/LqzamGMYFPR+CP4TCzY=; b=cug0w5wbZrPOFpFkuL160/eIkuPYdSTgNNzZQh5a3Ti0l5jmU5vBuvdk8iIkqsFK1Z sN4zypuBR+5IX3O0ZZM5pdvGDnzXQvASWUzxle5xosxiujL8//xtuB1756gW0dNCGxmQ a5zzOfU8QhbeTDdpxkQFBug4LPZNb3R1UPXWp0If5EfqBVLCRGvRkYDqC8wc6VVoTrdh mR56tpvPYu+d085vFum01urFcnRcJocP5d6lx1K7sXWFIKek8vh2WC7UfNbzywJ8MHld HLIEH/n9xjfrBdRYSgojdo6VaidSgWe1ZtoiciyJq+tWn7caBgVtx41qqVT3jtPoCS6L vaiQ== X-Gm-Message-State: ALoCoQkQWIGZiLOlZGWfeaTNgJzJew1JCxucWg+MJ+phs9H2emzguZMO6eK3g2+8/IozAb3hAetV X-Received: by 10.50.171.138 with SMTP id au10mr21103349igc.4.1413833303047; Mon, 20 Oct 2014 12:28:23 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id v8sm4950294ioe.16.2014.10.20.12.28.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 12:28:22 -0700 (PDT) Message-ID: <54456254.50201@andyet.net> Date: Mon, 20 Oct 2014 13:28:20 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <54442F52.3090608@andyet.net> <3A26E75E-BEF0-4D71-9372-01CE9D199E3D@cisco.com> In-Reply-To: <3A26E75E-BEF0-4D71-9372-01CE9D199E3D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fhTRDJRi6i-rIAT6rITMMS5JM8Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 19:28:27 -0000 On 10/20/14, 12:55 PM, Cullen Jennings (fluffy) wrote: > > So lets be clear here. Every time we checked, there has been > consensus that we need an MTI codec. So right now this work is sort > of blocked on that and we would like to get what people are calling > webrtc 1.0 out before the end of 2015. I think that a pragmatic look > at this would result there is at least some reasonable odds it might > take more than one or two meetings to resolve this if we end up in an > alternative consensus process. Given the parameters being assumed, you're probably right that several IETF meeting cycles will likely be needed. > You said on the list you felt "the state of video codec development > needs to evolve" before this discussions. I did not know what you > what you see needs to happen in this evolution and how long should we > wait before on this. I was wondering if you meant we should wait for > the IETF to standardize a video codec (like the netvc BOF is > proposing) but I really had no idea what you meant IMHO, if that working group had been formed after the video codec BoF two years ago, we might be further along toward a real solution. > Do you think there would be a better time to discuss this? When we can make a decision on a technical basis, not a political basis. The current situation involves "camps", as you say, and I just don't think that's a good foundation from which to make decisions. As things stand today, the most likely outcome appears to be "two MTIs" (which we've done in draft-ietf-rtcweb-audio so I suppose it's not the end of the world). Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Oct 20 12:42:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144B91ACC81 for ; Mon, 20 Oct 2014 12:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGfL8zA2_NGb for ; Mon, 20 Oct 2014 12:42:04 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ED01AC432 for ; Mon, 20 Oct 2014 12:42:04 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id v10so5511288pde.8 for ; Mon, 20 Oct 2014 12:42:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=UrTL59JwPZRHAnj+tcZc42nvx7XBNPMuuf3m88g7dHk=; b=lg8nVyLXEchMTuVW6YgoM9L1oHI2mAyyDEdIizVGS9PBoJQ+9o9iQX9BfclVYoBAMq ZDQgWJbmqUCJk7cAcyRnYfXEb1/+dPvbAZxYjpSLaJeg6yJkEVoJYTFRjop+kh+xeb9n Gda+081vKoXqzyd4danv5bQjXyZBQxy6gC2Nxo/fNUCMeIXjVGHwhKMPgg8+EkjYhM8Z FJVvqIy9BJkippIkllggQhc+NVyE/sJZzwt4Cp6QH97KmJwLxd3y52VjydwHDvFQs0g9 lX7xohrQQelS1bQj0uy8bGft1UcCBdZBRaAdn04Hr805u5nhoeind5Q31T0/GhuyT9Im iD7Q== X-Gm-Message-State: ALoCoQnpnRxTo5B3ktxLg/MOP6aIVb/ze6DObN6IZUoWoPBt/q5a9voySXM2c+GqT0W7iJYI7T5Q X-Received: by 10.66.184.76 with SMTP id es12mr29153844pac.3.1413834123689; Mon, 20 Oct 2014 12:42:03 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com. [209.85.220.54]) by mx.google.com with ESMTPSA id g13sm9950827pat.45.2014.10.20.12.42.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 12:42:02 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id ey11so5875558pad.13 for ; Mon, 20 Oct 2014 12:42:02 -0700 (PDT) X-Received: by 10.70.48.236 with SMTP id p12mr9906277pdn.95.1413834122692; Mon, 20 Oct 2014 12:42:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.170.172 with HTTP; Mon, 20 Oct 2014 12:41:42 -0700 (PDT) In-Reply-To: <3A26E75E-BEF0-4D71-9372-01CE9D199E3D@cisco.com> References: <54442F52.3090608@andyet.net> <3A26E75E-BEF0-4D71-9372-01CE9D199E3D@cisco.com> From: Emil Ivov Date: Mon, 20 Oct 2014 21:41:42 +0200 Message-ID: To: "Cullen Jenning (work)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xNvlHXxehWz-Ia6ArpLQ_pI9j58 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 19:42:06 -0000 On 20 Oct 2014 8:55 PM, "Cullen Jennings (fluffy)" wrote= : > > > So lets be clear here. Good idea! > Every time we checked, there has been consensus that we need an MTI codec= . > So right now this work is sort of blocked on that So clearly, what work is blocked on that exactly? > and we would like to get what people are calling webrtc 1.0 out before th= e end of 2015. I would love for that to happen as well. There are a bunch of pieces still being worked on but I can't find any that depend on the MTI debate happening. (Except for trickle ICE of course! The delay there is totally not the fault of the authors and entirely caused by the lack of an MTI video codec ;) ). > I think that a pragmatic look at this would result there is at least som= e reasonable odds it might take more than one or two meetings to resolve th= is if we end up in an alternative consensus process. It's probably worth distinguishing between finishing the technical and the administrative aspects of our work. I am sure that the latter would be much less dramatic. > You said on the list you felt "the state of video codec development needs= to evolve" before this discussions. I did not know what you what you see n= eeds to happen in this evolution and how long should we wait before on this= . I was wondering if you meant we should wait for the IETF to standardize a= video codec (like the netvc BOF is proposing) but I really had no idea wha= t you meant > > Do you think there would be a better time to discuss this? Well, for starters, it might be good to have some form of consensus already appearing plausible on the mailing list! Right now it seems we can't even agree to talk about it. > So far much of conversation has been folks in the Microsoft camp - keep i= n mind some of that group has said in the past they would be Hm ... I personally saw strong thread participation from Cisco employees ... but that might be because we attended different counting schools! ;) Emil -- https://jitsi.org From nobody Mon Oct 20 14:56:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B041ACF57 for ; Mon, 20 Oct 2014 14:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dhq9pX4lSaVQ for ; Mon, 20 Oct 2014 14:56:50 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A941ACF24 for ; Mon, 20 Oct 2014 14:56:50 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id a41so4139967yho.22 for ; Mon, 20 Oct 2014 14:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q1BMaNXpmFwu4fdU5EtVIOlCybMBbC0Rgz6mL8xISBU=; b=jhBD34R/eHOviyj2PjwO6zhaMopae5zPGQk8ObX9MWWYnKwtgRc3R4ygV70WFD3atu hJqJGCQ+c7yhCRlK5GBn41au/mgvCUQA4o0JVWBnq1mIYDprgKOhNpgsxiaqrTgZrqJ0 wEj+L5usyez3pOXqMDI+C6gdK+ulAAynsm7ZZKrpsqHwv2M7oFa4yK2ZaZeSsXUxSDiJ /1O78zXH2KKm82ITxeZDhWz5xfYAyTIjyibYUWXg//6qEUl1ipp53i+aRIH+PMFHDSel x6hJRXpoCCFdXVZVpWxnBNhNqLpEPKNs1GS/C34TdAXN8hwMLPwyomv1vA6cI/P2o6Yy oQzg== MIME-Version: 1.0 X-Received: by 10.236.230.104 with SMTP id i98mr6086039yhq.169.1413842209587; Mon, 20 Oct 2014 14:56:49 -0700 (PDT) Received: by 10.170.171.4 with HTTP; Mon, 20 Oct 2014 14:56:49 -0700 (PDT) Received: by 10.170.171.4 with HTTP; Mon, 20 Oct 2014 14:56:49 -0700 (PDT) In-Reply-To: <3A26E75E-BEF0-4D71-9372-01CE9D199E3D@cisco.com> References: <54442F52.3090608@andyet.net> <3A26E75E-BEF0-4D71-9372-01CE9D199E3D@cisco.com> Date: Tue, 21 Oct 2014 08:56:49 +1100 Message-ID: From: Silvia Pfeiffer To: Cullen Jennings Content-Type: multipart/alternative; boundary=089e01634d6cabc68f0505e1ca00 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xkXcRpyoRRMCaGt8PIKPHAqXn4A Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 21:56:51 -0000 --089e01634d6cabc68f0505e1ca00 Content-Type: text/plain; charset=UTF-8 On 21 Oct 2014 05:55, "Cullen Jennings (fluffy)" wrote: > > > So lets be clear here. Every time we checked, there has been consensus that we need an MTI codec. So right now this work is sort of blocked on that and we would like to get what people are calling webrtc 1.0 out before the end of 2015. I think that a pragmatic look at this would result there is at least some reasonable odds it might take more than one or two meetings to resolve this if we end up in an alternative consensus process. > > You said on the list you felt "the state of video codec development needs to evolve" before this discussions. I did not know what you what you see needs to happen in this evolution and how long should we wait before on this. I was wondering if you meant we should wait for the IETF to standardize a video codec (like the netvc BOF is proposing) but I really had no idea what you meant > > Do you think there would be a better time to discuss this? > > Cullen > > So far much of conversation has been folks in the Microsoft camp - keep in mind some of that group has said in the past they would be What's the Microsoft camp? This far I can see a VP8/9 camp and a H.264/5 camp and both camps have their reasons for making the respective choice. I think at this stage it's a religious discussion and not one likely to be resolved until a completely new and clearly superior codec in all discussed dimensions comes along. Is there really a point to spend more time discussing now? (BTW: I won't be at the meeting, so feel free to waste your time. Just saying...) Regards, Silvia. --089e01634d6cabc68f0505e1ca00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 21 Oct 2014 05:55, "Cullen Jennings (fluffy)" <fluffy@cisco.com> wrote:
>
>
> So lets be clear here. Every time we checked, there has been consensus= that we need an MTI codec. So right now this work is sort of blocked on th= at and we would like to get what people are calling webrtc 1.0 out before t= he end of 2015.=C2=A0 I think that a pragmatic look at this would result th= ere is at least some reasonable odds it might take more than one or two mee= tings to resolve this if we end up in an alternative consensus process.
>
> You said on the list you felt "the state of video codec developme= nt needs to evolve" before this discussions. I did not know what you w= hat you see needs to happen in this evolution and how long should we wait b= efore on this. I was wondering if you meant we should wait for the IETF to = standardize a video codec (like the netvc BOF is proposing) but I really ha= d no idea what you meant
>
> Do you think there would be a better time to discuss this?
>
> Cullen
>
> So far much of conversation has been folks in the Microsoft camp - kee= p in mind some of that group has said in the past they would be

What's the Microsoft camp? This far I can see a VP8/9 ca= mp and a H.264/5 camp and both camps have their reasons for making the resp= ective choice. I think at this stage it's a religious discussion and no= t one likely to be resolved until a completely new and clearly superior cod= ec in all discussed dimensions comes along. Is there really a point to spen= d more time discussing now?

(BTW: I won't be at the meeting, so feel free to waste y= our time. Just saying...)

Regards,
Silvia.

--089e01634d6cabc68f0505e1ca00-- From nobody Mon Oct 20 15:29:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50B1ACF5E for ; Mon, 20 Oct 2014 15:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyE1UpLlNwQG for ; Mon, 20 Oct 2014 15:29:36 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5759E1ACF08 for ; Mon, 20 Oct 2014 15:29:36 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id 29so629557yhl.41 for ; Mon, 20 Oct 2014 15:29:35 -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; bh=Sq0Lq/fKeD0AZynpyMclRbb7s112MkwEMOZf9JvNUlw=; b=mo+tRUm9X3Rc6bsOUkj/pZ5NMEXlsXuj3X04NFfcifGY3qMfXIj8xwIlftG8WmWBIe rxidvtVPgT/IKfZZ01xG/VSxOuXi/evE/p5c0TBYz/+yAgl2HZmgAj4kiudjleIc/UXy uUgxe4h1ljDdAiTJDQnOHYhMqLRlZgpvqWXT/mN7t126s1Lr4XDdSaB0cAMOIbNVzf0N X8I3ofhTiamTMYETUjjKfTwXOvp+HhJaZpS04kJ38Gn4Cl83TolW/iJWT9DPTcMA0ydH ROyrAmcPhjC5d3iK/of3Hjjk+QxxaveWktAWFFzn70TYRTFXIlJFBFLAmzgRCiMauzK4 ddPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Sq0Lq/fKeD0AZynpyMclRbb7s112MkwEMOZf9JvNUlw=; b=ClcHbH5ngbvUHxSqquZrZBG93mK8XmorLEGrwb3YA3PQnVtz8qFfxkXL/xi5o5alne HaaND9iOkDzrC/lAEA4YoJNfCYVrwXadXLmaGjMCQII/W9zPJ6tGdlFCizRK8xDX+mOl ONAcgoHYdSSF6uZvIl3/G6njfH4CHJkEIpJb/t9++wmW0lkx5zjP9T8VfxbhFDHEB2+R WA/D+B27uG0gh4gTcRVSCSnACfK8WP/d3QPy/Mq7irxTTOyU5CP2Eo1laYp3VUaWWOC5 jpnyXWOH6+G7Uor7cRH8+nsc7p/HVJSpvBzq6IxrgsPxnEYV9GIFMNRAQehFkbOuZj7p HFxQ== X-Gm-Message-State: ALoCoQmtYE1Nnplv+xWtARmygJ5ZoSVjyLheUK/Sbdp15niwxeOKcSDf0fLKGWVtbJ7dUPyWiN9i X-Received: by 10.52.0.98 with SMTP id 2mr21890216vdd.28.1413844175430; Mon, 20 Oct 2014 15:29:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 20 Oct 2014 15:29:15 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B2627F1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B2627F1@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Justin Uberti Date: Mon, 20 Oct 2014 15:29:15 -0700 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=047d7bacbbdcd846a20505e23fb5 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/o-ttF06H6ySOovIaQ5NA3vGeHs8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 22:29:41 -0000 --047d7bacbbdcd846a20505e23fb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >From the subject "Plan for MTI video codec", I thought this discussion was about video codecs, not AMR interop. An astute observer might take note of the fact that our inability to close the door on H.264 is providing an opportunity to other royalty-bearing codecs that want to join the party. On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > The scenario where you might want to transcode the audio codec is where > you have wideband audio in both the OPUS and the AMR, and you believe by > transcoding you can achieve a wideband quality, rather than falling back = to > G.711. And for interworking between 3GPP devices that are not using webRT= C, > the audio will still be AMR or AMR-WB or EVC, not OPUS. > > But audio transcoding is not particularly a concern for me. It is trying > where possible to avoid video transcoding. > > Keith > > ------------------------------ > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Andrew > Allen > *Sent:* 20 October 2014 14:52 > *To:* chris.cavigioli@intel.com; harald@alvestrand.no; > bernard.aboba@gmail.com > > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > Chris > > What is the scenario that dictates the need for direct transcoding betwee= n > OPUS and AMR? > > All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE > devices OPUS can be negotiated with non mobile RTCweb devices end to end. > > My expectation is that for mobile devices the RTCweb client will also hav= e > access to the embedded AMR codec so mobile RTCweb devices can interoperat= e > using AMR with non-RTCweb enabled mobile IMS devices that support AMR. > > For interoperation between non mobile RTCweb devices and mobile non RTCwe= b > IMS devices the non mobile RTCweb device can use G.711 to the transcoder > for transcoding to AMR on the other side. While not ideal this will be no > worse than non mobile RTCweb devices interoperating with circuit switched > only mobile devices which will be forced to interoperate via the PSTN. > > As RTCweb becomes universal on mobile devices I expect that support for > OPUS will become native and mobile IMS devices will also be able to use > OPUS even when operating without the use of the browser (i.e. in non RTCw= eb > mode) for better interoperation with non-mobile RTCweb devices. > > The lifetime of most mobile devices is 2 years or less so this is likely > to be mainly a short term transition issue only. > > Andrew > > *From*: Cavigioli, Chris [mailto:chris.cavigioli@intel.com] > *Sent*: Sunday, October 19, 2014 09:20 PM Eastern Standard Time > *To*: Harald Alvestrand ; Bernard Aboba < > bernard.aboba@gmail.com> > *Cc*: rtcweb@ietf.org > *Subject*: Re: [rtcweb] Plan for MTI video codec? > > > Harald said: > > =E2=80=9CWe made the mistake of having an MTI discussion previously with = not > enough details on that subject=E2=80=A6=E2=80=9D > > > > We didn=E2=80=99t have quantitative data earlier for a data-driven decisi= on. > Future Web =E2=80=93 LTE interop is important. A group of us in GSMA hav= e been > looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based > voice/video/messaging), specifically looking at user experience impact of > latency introduced by added in-network transcoding. GSMA has approved th= e > whitepaper and it is being prepared for public distribution. > > > > WebRTC =E2=80=93 LTE transcoding is now MANDATORY because of =E2=80=9CWeb= RTC Audio Codec > and Processing Requirements=E2=80=9D. > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio > codecs in WebRTC and in LTE are dissimilar. Thus, REGARDLESS of the vide= o > codecs, there is already a significant degradation imposed on Web =E2=80= =93 LTE > links if only MTI codecs are used. The only systems to avoid this are > those which implement OPTIONAL audio codecs to be transcoder-free with > LTE. The same can apply for video codecs. > > > > The GSMA whitepaper refers to: > > 1. Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by > 3GPP SA4 in August 2014. To paraphrase, performance objectives for maxim= um > VoLTE device delays in error and jitter free conditions and AMR speech > codec operation, the sum of the UE delays in sending and receiving > directions (TS + TR) should be =E2=89=A4 150ms. If this performance objec= tive > cannot be met, the sum of the UE delays in sending and receiving directio= ns > (TS + TR) shall in any case be =E2=89=A4 190ms. > > 2. OPUS =E2=80=93 AMR transcoding adds an additional 211.5 ms > implementation-agnostic (TS + TR) delay, including 40 ms for jitter > buffer and 40 ms for discontinuous reception (DRX). > > 3. To put these numbers in perspective, it is in general desirable to > minimize UE delays to ensure low enough end-to-end delays and hence a goo= d > conversational experience. Increasing delay causes people to double-talk > making conversations increasingly frustrating. Guidance to stay below 40= 0 > ms maximum one-way delay is found in ITU-T Recommendation G.114 and the > computational E-model is in ITU-T Recommendation G.107. > > > > This is a complex topic with many network factors in play. LTE operators > in 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS =E2=80=93 AM= R > transcoding in the network imposes an additional 211.5 ms on top of that, > just for audio. Optionally using AMR in WebRTC, those 211.5 ms can be > eliminated, delivering a superior end-user experience. > > > > CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a good > WebRTC =E2=80=93 LTE interop experience, emerging WebRTC systems must acc= ommodate > MTI codecs already deployed in the LTE domain and in mobile operating > systems, namely AMR/AMR-WB and H.264. > > > > POSITION: To be clear, several Intel SoCs launched at MWC this year for > smartphones and tablets support both VP8 and H.264 hardware encode and > decode =E2=80=93 so Intel is codec-neutral in this MTI debate. Additiona= lly, Intel > has high-performance solutions for transcoding. However, we wish to info= rm > the industry, with quantitative data, about impact to end-user experience > of mandating such transcoding so IETF can make a data-driven decision on > video codecs as well as reflect on the impact of already having mandated > transcoding on the audio side. > > > > Chris Cavigioli > > Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile > and Communications Group (MCG) > > +1 (415) 254-4545 mobile > > +1 (408) 653-8348 desk > > +1 (408) 884-2400 fax > > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review or distribution by others i= s > strictly prohibited. If you are not the intended recipient, please contac= t > the sender and delete all copies. > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Bernard > Aboba > *Sent:* Sunday, October 19, 2014 2:29 PM > *To:* Harald Alvestrand > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Harald said: > > > > "Bernard, > > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad....." > > > > [BA] I agree that the lack of interoperability is largely "codec > independent": that is, implementations based on different mechanisms fo= r > congestion control, repair, etc. will exhibit interoperability problems, > regardless of the codec chosen. The real test for RTCWEB will be to mov= e > beyond "interoperability of implementations sharing source code" to > "interoperability of independent implementations, based on open standards= ". > > > > > On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand > wrote: > > On 10/19/2014 05:43 PM, Bernard Aboba wrote: > > "And its one of the issues holding up wider adoption of the technology" > > > > [BA] Specifying an MTI encoder/decoder is not sufficient for > interoperability. It is also necessary to specify the transport in enoug= h > detail to allow independent implementations that interoperate well enough > to be usable in a wide variety of scenarios, including wireless networks > where loss is commonly experienced. > > > Bernard, > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad..... > > > > > > > We made the mistake of having an MTI discussion previously with not enoug= h > details on that subject, particularly with respect to H.264. > draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > > > > So if we are to have the discussion again, it should occur in the context > of detailed specifications and interoperability reports. > > > > > > > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: > > I'm in favor of taking another run at this. > > > > The working group has repeatedly said that an MTI codec is something we > need to produce. And its one of the issues holding up wider adoption of t= he > technology (not the only one for sure). > > > > And things have changed since the last meeting, a year ago now (November > in Vancouver). Cisco's open264 plugin shipped and now just recently is > integrated into Firefox. iOS8 shipped with APIs for H264. There are other > things worth noting. Will this change the minds of everyone? Surely not. > Will it sway enough for us to achieve rough consensus? Maybe. IMHO - wort= h > finding out. > > > > On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < > agouaillard@gmail.com> wrote: > > +1 to not having MTI codec discussion unless some progress has been made > on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that ther= e > was no change on the members position. > > > > On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: > > On 10/17/2014 12:02 AM, Bernard Aboba wrote: > > One thing we could do instead of wasting time on MTI is to actually make > progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could > actually interoperate regardless of the codec. > > > The big argument for an MTI is actually the one stated in -overview: It > guards against interoperability failure. > > I would like to have an ecosystem where one can field a box, connect it t= o > everything else, and run well for *some* level of "well" - and I would > prefer that ecosystem to be one where it's possible to field the box > without making prior arrangements with anyone about licenses. > > This argument hasn't changed one whit since last time we discussed it. An= d > I don't see much movement on the specifics of the proposals either. > > We'll have to interoperate well with the codecs we field. So using some > time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn= 't > finished either. There's one sentence that needs to be removed.) > > I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd > prefer to re-discuss based on the knowledge that some significant players > have actually changed their minds. > > At the moment, I don't see signs that any of the poll respondents have > said "I have changed my mind". > > Harald > > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: > > On 16 October 2014 14:17, Matthew Kaufman wrote: > And that's because something substantive has changed, or simply because > wasting the WG time on this again is more entertaining than actually > finishing a specification that can be independently implemented by all > browser vendors? (A specification that we are nowhere near having, as far > as > I can tell) > > Personally, I've found the reprieve from this fight refreshing. And > it would appear that we've made some real progress as a result. I'd > suggest that if we don't have new information, we continue to spend > our time productively. If we can't find topics to occupy our meeting > agenda time, then maybe we can free an agenda slot. > > _______________________________________________ > 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 > > > > > > -- > > Alex. Gouaillard, PhD, PhD, MBA > > > -------------------------------------------------------------------------= ----------- > > CTO - Temasys Communications, S'pore / Mountain View > > President - CoSMo Software, Cambridge, MA > > > -------------------------------------------------------------------------= ----------- > > sg.linkedin.com/agouaillard > > =C2=B7 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > 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 > > > > -- > > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > 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 > > --047d7bacbbdcd846a20505e23fb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From the subject "Plan for MTI video codec", I t= hought this discussion was about video codecs, not AMR interop.=C2=A0
<= br>
An astute observer might take note of the fact that our inabi= lity to close the door on H.264 is providing an opportunity to other royalt= y-bearing codecs that want to join the party.

On Mon, Oct 20, 2014 at 7:34 AM, DR= AGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
The scenario where you might want to transcode the audio codec is where y= ou have wideband audio in both the OPUS and the AMR, and you believe by tra= nscoding you can achieve a wideband quality, rather than falling back to G.711. And= for interworking between 3GPP devices that are not using webRTC, the audio= will still be AMR or AMR-WB or EVC, not OPUS.
=C2=A0
But audio transcoding is not particularly a concern for me. It is trying = where possible to avoid video transcoding.
=C2=A0
Keith

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen
Sent: 20 October 2014 14:52
To: c= hris.cavigioli@intel.com; harald@alvestrand.no; bernard.aboba@gmail.com
=
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?


Chris

What is the scenario that dictates the need for direct transcoding between = OPUS and AMR?

All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE devi= ces OPUS can be negotiated with non mobile RTCweb devices end to end.

My expectation is that for mobile devices the RTCweb client will also have = access to the embedded AMR codec so mobile RTCweb devices can interoperate = using AMR with non-RTCweb enabled mobile IMS devices that support AMR.

For interoperation between non mobile RTCweb devices and mobile non RTCweb = IMS devices the non mobile RTCweb device can use G.711 to the transcoder fo= r transcoding to AMR on the other side. While not ideal this will be no wor= se than non mobile RTCweb devices interoperating with circuit switched only mobile devices which will be for= ced to interoperate via the PSTN.

As RTCweb becomes universal on mobile devices I expect that support for OPU= S will become native and mobile IMS devices will also be able to use OPUS e= ven when operating without the use of the browser (i.e. in non RTCweb mode)= for better interoperation with non-mobile RTCweb devices.

The lifetime of most mobile devices is 2 years or less so this is likely to= be mainly a short term transition issue only.

Andrew
=C2=A0
From: Cavigioli, Chris [mailto:chris.cavigioli@intel.com]
Sent: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
To: Harald Alvestrand <harald@alvestrand.no>; Bernard Aboba <bernard.aboba@gmail.com>
Cc: rtcweb@ietf= .org <rtcweb@ie= tf.org>
Subject: Re: [rtcweb] Plan for MTI video codec?
=C2=A0

Harald said:=C2=A0

=E2=80=9CWe made the mistake of having an MTI discus= sion previously with not enough details on that subject=E2=80=A6=E2=80=9D

=C2=A0

We didn=E2=80=99t have quantitati= ve data earlier for a data-driven decision.=C2=A0 Future Web =E2=80=93 LTE = interop is important.=C2=A0 A group of us in GSMA have been looking at WebR= TC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messagin= g), specifically looking at user experience impact of latency introduced by= added in-network transcoding.=C2=A0 GSMA has approved the whitepaper and i= t is being prepared for public distribution.=C2=A0

=C2=A0

WebRTC =E2=80=93 LTE transcoding = is now MANDATORY because of =E2=80=9CWebRTC Audio Codec and Processing Requ= irements=E2=80=9D. http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where M= TI audio codecs in WebRTC and in LTE are dissimilar.=C2=A0 Thus, REGARDLESS= of the video codecs, there is already a significant degradation imposed on Web =E2=80=93 LTE links if only MTI codecs are used.=C2=A0 The = only systems to avoid this are those which implement OPTIONAL audio codecs = to be transcoder-free with LTE.=C2=A0 The same can apply for video codecs.<= u>

=C2=A0

The GSMA whitepaper refers to:=

1.=C2=A0=C2=A0=C2=A0=C2=A0 Quantitative voice-over-LTE = (VoLTE) delay limits were agreed-to by 3GPP SA4 in August 2014.=C2=A0 To pa= raphrase, performance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec ope= ration, the sum of the UE delays in sending and receiving directions (TS + TR) should be =E2=89=A4 150ms. If this performance ob= jective cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR)= shall in any case be =E2=89=A4 190ms.

2.=C2=A0=C2=A0=C2=A0=C2=A0 OPUS =E2=80=93 AMR transcodi= ng adds an additional 211.5 ms implementation-agnostic (TS + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.=C2=A0=C2=A0=C2=A0=C2=A0 To put these numbers in pers= pective, it is in general desirable to minimize UE delays to ensure low eno= ugh end-to-end delays and hence a good conversational experience.=C2=A0 Increasing delay causes people to double-talk making con= versations increasingly frustrating.=C2=A0 Guidance to stay below 400 ms ma= ximum one-way delay is found in ITU-T Recommendation G.114 and the computat= ional E-model is in ITU-T Recommendation G.107.

=C2=A0

This is a complex topic with many= network factors in play.=C2=A0 LTE operators in 3GPP seek UE delays (TS + TR) around 150 ms.=C2=A0 Adding OPUS =E2=80=93 AMR transcoding in the network imposes an additional 211.5 ms on= top of that, just for audio.=C2=A0 Optionally using AMR in WebRTC, those 2= 11.5 ms can be eliminated, delivering a superior end-user experience.=C2=A0

=C2=A0

CONCLUSION: =C2=A0regardless of M= TI codec choices in WebRTC, to provide a good WebRTC =E2=80=93 LTE interop = experience, emerging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely= AMR/AMR-WB and H.264.

=C2=A0

POSITION:=C2=A0 To be clear, seve= ral Intel SoCs launched at MWC this year for smartphones and tablets suppor= t both VP8 and H.264 hardware encode and decode =E2=80=93 so Intel is codec-neutral in this MTI debate.=C2=A0 Additionally, Intel has h= igh-performance solutions for transcoding.=C2=A0 However, we wish to inform= the industry, with quantitative data, about impact to end-user experience = of mandating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impa= ct of already having mandated transcoding on the audio side.<= /span>

=C2=A0

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group (MCG)

+1 (415) 254-4545 = mobile

+1 (408) 653-8348 = desk

+1 (408) 884-2400 = fax

This e-mail may contain confident= ial and privileged material for the sole use of the intended recipient(s).= =C2=A0 Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the send= er and delete all copies.

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf= .org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?=

=C2=A0

Harald said:=C2=A0

=C2=A0

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad....."=

=C2=A0

[BA] =C2=A0I agree that the lack of interoperability= is largely "codec independent": =C2=A0 that is, implementations = based on different mechanisms for congestion control, repair, etc. will exh= ibit interoperability problems, regardless of the codec chosen. =C2=A0 The real test for RTCWEB will be to move beyond "inter= operability of implementations sharing source code" =C2=A0to "int= eroperability of independent implementations, based on open standards"= . =C2=A0=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:<= u>

"And its one of the issues holding up wider ado= ption of the technology"

=C2=A0

[BA] Specifying an MTI encoder/decoder is not suffic= ient for interoperability.=C2=A0 It is also necessary to specify the transp= ort in enough detail to allow independent implementations that interoperate= well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienc= ed.=C2=A0


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....




=C2=A0

We made the mistake of having an MTI discussion prev= iously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.= =C2=A0

=C2=A0

So if we are to have the discussion again, it should= occur in the context of detailed specifications and interoperability repor= ts.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrose= n.net> wrote:

I'm in favor of taking another run at this. <= /u>

=C2=A0

The working group has repeatedly said that an MTI co= dec is something we need to produce. And its one of the issues holding up w= ider adoption of the technology (not the only one for sure).<= /p>

=C2=A0

And things have changed since the last meeting, a ye= ar ago now (November in Vancouver). Cisco's open264 plugin shipped and = now just recently is integrated into Firefox. iOS8 shipped with APIs for H2= 64. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough fo= r us to achieve rough consensus? Maybe. IMHO - worth finding out.=

=C2=A0

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLAR= D <agouaillar= d@gmail.com> wrote:

+1 to not having MTI codec discussion unless some pr= ogress has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing= harald's =C2=A0feeling that there was no change on the members positio= n.=C2=A0

=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:<= u>

One thing we could do instead of wasting time on MTI= is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-vi= deo, so we could actually interoperate regardless of the codec.


The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald





On Oct 16, 2014, at 2:2= 8 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at>= ; wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)

Personally, I've found the reprieve from this fi= ght refreshing.=C2=A0 And
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



=C2=A0

--

Alex. Gouaillard, PhD,= PhD, MBA

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

CTO - Temasys Communic= ations, S'pore / Mountain View

President - CoSMo Soft= ware, Cambridge, MA

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

=C2=B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0


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



=C2=A0

--


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

=C2=A0

=C2=A0 

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

=C2=A0 

-- 
Surveillance is pervasive. Go Dark.


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

=C2=A0


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


--047d7bacbbdcd846a20505e23fb5-- From nobody Mon Oct 20 15:46:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548971ACF99 for ; Mon, 20 Oct 2014 15:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oqAeyaVKeK6 for ; Mon, 20 Oct 2014 15:46:31 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E201ACF98 for ; Mon, 20 Oct 2014 15:46:30 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so25487wgh.4 for ; Mon, 20 Oct 2014 15:46:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5qmoQe4jaiwWvgAqKBhRVNKGYF6mzdhmvTMX29McH/g=; b=hyL6uwbuHc5J2mDB5yYGYiioO1/23mRScAoXAJhkEKyxFXNgXiPJbCZ0mOG/sKm8qM lQ4GhPCdYdiGugr0VsZF+rv8ZQUSY31tCTBryHuh5LB5HCQXcsMs9lUzQETnWJZ2qz9D ftuYJT7cyiLYprxAIXvc9DgLWcDdG/yREqhWvPkTtPu/1pgeij4ul7/+wCpzKFdMQnDR omHquXKE0GOolSKztNvuequLmvqZteUKSw10LQ5zMAro1UHLpr21lHeAz/W7TWYC638e IHGdgmM0jxmVITYt/3UPf5bV7NeGXAnyenL8UHV1n5VUzZ8l7ECigNZRSdtmtU7CUwA4 AR/g== X-Gm-Message-State: ALoCoQlk6uaPQZIRf0dZUFKll/1poBCPtIxHufPpPFu7dwYiL7IMOSKT4uohmDMgVx85IqNmZC4H X-Received: by 10.194.63.145 with SMTP id g17mr30966855wjs.80.1413845189567; Mon, 20 Oct 2014 15:46:29 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com. [209.85.212.172]) by mx.google.com with ESMTPSA id nf6sm11085075wic.11.2014.10.20.15.46.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 15:46:28 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so8459914wiv.5 for ; Mon, 20 Oct 2014 15:46:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.126.9 with SMTP id mu9mr24333015wib.38.1413845187836; Mon, 20 Oct 2014 15:46:27 -0700 (PDT) Received: by 10.216.176.65 with HTTP; Mon, 20 Oct 2014 15:46:27 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Date: Mon, 20 Oct 2014 18:46:27 -0400 Message-ID: From: Roman Shpount To: Jonathan Rosenberg Content-Type: multipart/alternative; boundary=e89a8f839d293048050505e27c75 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6jJ3RpaMbG37FjWKRLMVlzoWVio Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 22:46:36 -0000 --e89a8f839d293048050505e27c75 Content-Type: text/plain; charset=UTF-8 Unless H.264 became royalty free or royalty free profile for H.264 is developed (and I am talking about ability to include any implementation of this H.264 profile into any project without paying royalties, not linking to something the end user must download), H.264 would not be acceptable to me as an MTI. All the other news updates regarding H.264 are irrelevant. I would assume most open source developer or smaller software developers would share my opinion. Settled law suits regarding VP8 also do not provide a significant change regarding video MTI. There is nothing here to discuss except that we all want video MTI, but we cannot agree on one. Why waste time on this? _____________ Roman Shpount On Sun, Oct 19, 2014 at 2:13 PM, Jonathan Rosenberg wrote: > @Alexandre - you say "Today, nothing has changed with respect to those > two items (even though providing open264 royalties and absorbing the > license cost for some platforms might have been a set in the right > direction). ". But, as you say, the availability of Firefox with H264 is a > change (previously it was not yet available); the fact that Cisco has in > fact fronted the cost is a change (at the last meeting some were skeptical > this would happen, but it has). The other big news was IOS8, which now > enables apps to access H264 and Apple pays the cost. Last time, the lack of > a solution on IOS was a big deal. That is also now, no longer an issue. As > such I think there are material changes. > > > On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD < > agouaillard@gmail.com> wrote: > >> @jonathan, >> >> while you are right and availability of 264 implementation or hardware >> acceleration has improved, it has never been reported as a problem in the >> previous pool by anyone. The 264 royalties, and the VP8 IP risks were, >> AFAIR, the main reasons used by individuals to justify their positions. >> Today, nothing has changed with respect to those two items (even though >> providing open264 royalties and absorbing the license cost for some >> platforms might have been a set in the right direction). This is why I >> think the conditions are not met for a consensus to be reached. >> >> Alex. >> >> >> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba >> wrote: >> >>> "And its one of the issues holding up wider adoption of the technology" >>> >>> [BA] Specifying an MTI encoder/decoder is not sufficient for >>> interoperability. It is also necessary to specify the transport in enough >>> detail to allow independent implementations that interoperate well enough >>> to be usable in a wide variety of scenarios, including wireless networks >>> where loss is commonly experienced. >>> >>> We made the mistake of having an MTI discussion previously with not >>> enough details on that subject, particularly with respect to H.264. >>> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. >>> >>> So if we are to have the discussion again, it should occur in the >>> context of detailed specifications and interoperability reports. >>> >>> >>> >>> >>> >>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg >> > wrote: >>> >>>> I'm in favor of taking another run at this. >>>> >>>> The working group has repeatedly said that an MTI codec is something we >>>> need to produce. And its one of the issues holding up wider adoption of the >>>> technology (not the only one for sure). >>>> >>>> And things have changed since the last meeting, a year ago now >>>> (November in Vancouver). Cisco's open264 plugin shipped and now just >>>> recently is integrated into Firefox. iOS8 shipped with APIs for H264. There >>>> are other things worth noting. Will this change the minds of everyone? >>>> Surely not. Will it sway enough for us to achieve rough consensus? Maybe. >>>> IMHO - worth finding out. >>>> >>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < >>>> agouaillard@gmail.com> wrote: >>>> >>>>> +1 to not having MTI codec discussion unless some progress has been >>>>> made on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that >>>>> there was no change on the members position. >>>>> >>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand < >>>>> harald@alvestrand.no> wrote: >>>>> >>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>>>> >>>>>>> One thing we could do instead of wasting time on MTI is to actually >>>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >>>>>>> actually interoperate regardless of the codec. >>>>>>> >>>>>> >>>>>> The big argument for an MTI is actually the one stated in -overview: >>>>>> It guards against interoperability failure. >>>>>> >>>>>> I would like to have an ecosystem where one can field a box, connect >>>>>> it to everything else, and run well for *some* level of "well" - and I >>>>>> would prefer that ecosystem to be one where it's possible to field the box >>>>>> without making prior arrangements with anyone about licenses. >>>>>> >>>>>> This argument hasn't changed one whit since last time we discussed >>>>>> it. And I don't see much movement on the specifics of the proposals either. >>>>>> >>>>>> We'll have to interoperate well with the codecs we field. So using >>>>>> some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 >>>>>> isn't finished either. There's one sentence that needs to be removed.) >>>>>> >>>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >>>>>> prefer to re-discuss based on the knowledge that some significant players >>>>>> have actually changed their minds. >>>>>> >>>>>> At the moment, I don't see signs that any of the poll respondents >>>>>> have said "I have changed my mind". >>>>>> >>>>>> Harald >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson < >>>>>>>> martin.thomson@gmail.com> wrote: >>>>>>>> >>>>>>>> On 16 October 2014 14:17, Matthew Kaufman >>>>>>>>> wrote: >>>>>>>>> And that's because something substantive has changed, or simply >>>>>>>>> because >>>>>>>>> wasting the WG time on this again is more entertaining than >>>>>>>>> actually >>>>>>>>> finishing a specification that can be independently implemented by >>>>>>>>> all >>>>>>>>> browser vendors? (A specification that we are nowhere near having, >>>>>>>>> as far as >>>>>>>>> I can tell) >>>>>>>>> >>>>>>>> Personally, I've found the reprieve from this fight refreshing. And >>>>>>>> it would appear that we've made some real progress as a result. I'd >>>>>>>> suggest that if we don't have new information, we continue to spend >>>>>>>> our time productively. If we can't find topics to occupy our >>>>>>>> meeting >>>>>>>> agenda time, then maybe we can free an agenda slot. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Alex. Gouaillard, PhD, PhD, MBA >>>>> >>>>> ------------------------------------------------------------------------------------ >>>>> CTO - Temasys Communications, S'pore / Mountain View >>>>> President - CoSMo Software, Cambridge, MA >>>>> >>>>> ------------------------------------------------------------------------------------ >>>>> sg.linkedin.com/agouaillard >>>>> >>>>> - >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>>> >>>> >>>> >>>> -- >>>> Jonathan Rosenberg, Ph.D. >>>> jdrosen@jdrosen.net >>>> http://www.jdrosen.net >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>> >> >> >> -- >> Alex. Gouaillard, PhD, PhD, MBA >> >> ------------------------------------------------------------------------------------ >> CTO - Temasys Communications, S'pore / Mountain View >> President - CoSMo Software, Cambridge, MA >> >> ------------------------------------------------------------------------------------ >> sg.linkedin.com/agouaillard >> >> - >> >> > > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --e89a8f839d293048050505e27c75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Unless H.264 became royalty free or royalty free profile f= or H.264 is developed (and I am talking about ability to include any implem= entation of this H.264 profile into any project without paying royalties, n= ot linking to something the end user must =C2=A0download), H.264 would not = be acceptable to me as an MTI. All the other news updates regarding H.264 a= re irrelevant. I would assume most open source developer or smaller softwar= e developers would share my opinion.

Settled law suits r= egarding VP8 also do not provide a significant change regarding video MTI.<= /div>

There is nothing here to discuss except that we al= l want video MTI, but we cannot agree on one. Why waste time on this?
=

_____________
Ro= man Shpount

On Sun, Oct 19, 2014 at 2:13 PM, Jonathan Ro= senberg <jdrosen@jdrosen.net> wrote:
@Alexandre - you say "Today, nothing has changed with = respect to those two items (even though providing open264 royalties and abs= orbing the license cost for some platforms might have been a set in the rig= ht direction).=C2=A0". But, as you say, the availability of Firefox wi= th H264 is a change (previously it was not yet available); the fact that Ci= sco has in fact fronted the cost is a change (at the last meeting some were= skeptical this would happen, but it has). The other big news was IOS8, whi= ch now enables apps to access H264 and Apple pays the cost. Last time, the = lack of a solution on IOS was a big deal. That is also now, no longer an is= sue. As such I think there are material changes.


On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:
@jonathan,

while you are right an= d availability of 264 implementation or hardware acceleration has improved,= it has never been reported as a problem in the previous pool by anyone. Th= e 264 royalties, and the VP8 IP risks were, AFAIR, the main reasons used by= individuals to justify their positions. Today, nothing has changed with re= spect to those two items (even though providing open264 royalties and absor= bing the license cost for some platforms might have been a set in the right= direction). This is why I think the conditions are not met for a consensus= to be reached.

Alex.


On Sun, O= ct 19, 2014 at 11:43 PM, Bernard Aboba <bernard.aboba@gmail.com&= gt; wrote:
= "And its one of the issues holding up wider adoption of the technology= "

[BA] Specifying an MTI encoder/decoder is = not sufficient for interoperability.=C2=A0 It is also necessary to specify = the transport in enough detail to allow independent implementations that in= teroperate well enough to be usable in a wide variety of scenarios, includi= ng wireless networks where loss is commonly experienced. =C2=A0
<= br>
We made the mistake of having an MTI discussion previously wi= th not enough details on that subject, particularly with respect to H.264. = draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. =C2=A0

So if we are to have the discussion again, it shoul= d occur in the context of detailed specifications and interoperability repo= rts.

=C2=A0

=C2=A0
<= /div>

On= Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
I&#= 39;m in favor of taking another run at this.

The working= group has repeatedly said that an MTI codec is something we need to produc= e. And its one of the issues holding up wider adoption of the technology (n= ot the only one for sure).

And things have changed= since the last meeting, a year ago now (November in Vancouver). Cisco'= s open264 plugin shipped and now just recently is integrated into Firefox. = iOS8 shipped with APIs for H264. There are other things worth noting. Will = this change the minds of everyone? Surely not. Will it sway enough for us t= o achieve rough consensus? Maybe. IMHO - worth finding out.

On Sat, Oct= 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <agouaillard@gmail.com&= gt; wrote:
+1 to = not having MTI codec discussion unless some progress has been made on VP8 a= t MPEG.=C2=A0Any news on that? I'm sharing harald's =C2=A0feeling t= hat there was no change on the members position.=C2=A0

On Fri, Oct 17, 2014 a= t 9:22 PM, Harald Alvestrand <harald@alvestrand.no> wrote= :
On 10/17/2014 12:02 AM, Bernard A= boba wrote:
One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)
Personally, I've found the reprieve from this fight refreshing.=C2=A0 A= nd
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



<= /div>--
Alex. Gouaillard= , PhD, PhD, MBA
-------------------------------------------------------= -----------------------------
CTO - Temasys Communications, S'= ;pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------= ------------------

  • =

_______________________________________________
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





--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President = - CoSMo Software, Cambridge, MA
---------------------------------= ---------------------------------------------------




--
=

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


--e89a8f839d293048050505e27c75-- From nobody Mon Oct 20 15:51:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D1F1ACF99 for ; Mon, 20 Oct 2014 15:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee6dPXtUzaLg for ; Mon, 20 Oct 2014 15:51:21 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A561ACF98 for ; Mon, 20 Oct 2014 15:51:20 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id q108so24601qgd.11 for ; Mon, 20 Oct 2014 15:51:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=89hl60pg55UBPXeAk2+c0b84GNGCra48C4OY0FhjVIE=; b=h9n4SEM54sq4dLKSTrCE1pl5FQ+hli1XgTrbKRr7hOIxCtOzILMh36Sn7TMM0uzQ7i 2XauGvgEVgbXsqwkLQGfdR2Sd0KzY27t8SCiQjigzw+1lsNvWlUGlWKtmHc+LU43MuDs j18w5Uer9iDqSjyQRUWtP5l98WNP56nSbMJXKH6G+igFPAKjnjKhHxRONbl8cdi3CbA1 e5TlDC6/PwfObzzaaADj4YyPjiQc5XK/nmdxupg1ag4nyVeOOuFey06mYL7mGey3fW0x M9Pv48Vss329xSXVdO00r1+D5tLLYEwK665wwt2zvyYfqw9XCI/U3vHJjtnAggMYBmot 5ujA== X-Gm-Message-State: ALoCoQmABO2f+spWyLCuJyxZ6dKl7PzRbn5FgJMYzdXaMpZTL+PSiiyXYXGCWjDh4IrW3QRbjPv9 X-Received: by 10.140.21.199 with SMTP id 65mr37764866qgl.86.1413845479915; Mon, 20 Oct 2014 15:51:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Mon, 20 Oct 2014 15:50:59 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 Oct 2014 00:50:59 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eTNKmlzoFweL_WtmTr2MU46VEjE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 22:51:22 -0000 2014-10-21 0:46 GMT+02:00 Roman Shpount : > Unless H.264 became royalty free or royalty free profile for H.264 is > developed (and I am talking about ability to include any implementation o= f > this H.264 profile into any project without paying royalties, not linking= to > something the end user must download), H.264 would not be acceptable to = me > as an MTI. All the other news updates regarding H.264 are irrelevant. I > would assume most open source developer or smaller software developers wo= uld > share my opinion. +1 --=20 I=C3=B1aki Baz Castillo From nobody Mon Oct 20 16:27:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3831ACE4F for ; Mon, 20 Oct 2014 16:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBOnLKgTqaP4 for ; Mon, 20 Oct 2014 16:27:14 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E6B1ACE1B for ; Mon, 20 Oct 2014 16:27:14 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so60527lab.2 for ; Mon, 20 Oct 2014 16:27: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:from:date:message-id:subject:to :cc:content-type; bh=2BviouBlUZXUwL3wgbLRfxmmf31wo7XiTDjE0HJ45mc=; b=Yizk9kp3xoz752yc6Ge2nf7uaXvlhR62uDd0bdXRx+U7Oe2w7ekK46Kpx5qrjjbsUL 0YWboPN2iT6r3T7ZZz5O1zT4Es+APz1t79SQXAEycQPy74HeM257OJ/4FkxpN89Rz2pW fF7o2QViD1C16OUohRAPNfVhXr4HKMA7owPyvCUYfPk17/hIYCY3DNmK1dXEvVTxa68l B62o5bRDveT5EIwahp9Sxld7+9vCuP90zW2b1hHWeRAbmIx+B/qnlrge8tOcBzkzDfMt 0vzqFG0fy+bRGwY5NXdcvUHP5ZCjsplDq55+UA5VdcI2e+aLDFgtW7oKWgfJJU2utw2M VrsA== X-Received: by 10.112.85.106 with SMTP id g10mr30292642lbz.38.1413847632671; Mon, 20 Oct 2014 16:27:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.83.136 with HTTP; Mon, 20 Oct 2014 16:26:52 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> From: Barry Dingle Date: Tue, 21 Oct 2014 10:26:52 +1100 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11349882e979090505e30d13 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GezFqn5xhfbTygJ3WH8xssQkcgg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 23:27:16 -0000 --001a11349882e979090505e30d13 Content-Type: text/plain; charset=UTF-8 Martin, Sorry for the confusion. I was trying to use 'network scenario' as a general term to encompass different end-to-end call situations that involve my WebRTC network and the destination network e.g. mobile, PSTN, VoIP, existing Video Services etc. (Opposite call directions also apply of course.) I am suggesting that there should be MTI's for several major end-to-end network scenarios as that is something that the IETF can specify. HOW the small range of MTI's are Implemented is up to Browsers and the Browsers can be categorised according to their support of the different network scenarios. The Browsers are the key to what codecs are supported. Trying to force people by Specification to implement something they do not want to support (for whatever reason) is what is causing us this video codec MTI debate to be unsolvable. The IETF Specifications should describe what protocols etc are needed for interoperability. A separate document can describe which options (in this case codecs) to use in different end-to-end network scenarios. That is, the 'case-specific' MTIs. Barry Dingle Fixed - +61(0)3-9725-3937 Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Australia On Mon, Oct 20, 2014 at 11:02 PM, Martin Thomson wrote: > On 20 October 2014 01:52, Barry Dingle wrote: > > Rather, we should have 2 (or more) Network Scenarios and have Audio+Video > > MTI's for Each Network Scenario. > > > Why should your network attachment conditions determine who you can talk > to? > --001a11349882e979090505e30d13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin,

Sorry for the confusion. I= was trying to use 'network scenario' as a general term to encompas= s different end-to-end call situations that involve my WebRTC network and t= he destination network e.g. mobile, PSTN, VoIP, existing Video Services etc= . (Opposite call directions also apply of course.)

I am sugge= sting that there should be MTI's for several major end-to-end network s= cenarios as that is something that the IETF can specify. HOW the small rang= e of MTI's are Implemented is up to Browsers and the Browsers can be ca= tegorised according to their support of the different network scenarios.=C2= =A0

The= Browsers are the key to what codecs are supported. Trying to force people = by Specification to implement something they do not want to support (for wh= atever reason) is what is causing us this video codec MTI debate to be unso= lvable.

The IETF Specifications sh= ould describe what protocols etc are needed for interoperability. A separat= e document can describe which options (in this case codecs) to use in diffe= rent end-to-end network scenarios. That is, the 'case-specific' MTI= s.

Barry Din= gle
Fixed - +61(0)3-9725-3937=C2=A0 =C2=A0 Mob - +61(0)41-911-7578=C2=A0= =C2=A0
Fellow of University of Melbourne, Australia

On Mon, Oct 20, 2014 at 11:02 PM, Martin Tho= mson <martin.thomson@gmail.com> wrote:
On 20 October 2014 = 01:52, Barry Dingle <btdingle@gmai= l.com> wrote:
> Rather, we should have 2 (or more) Network Scenarios and have Audio+Vi= deo
> MTI's for Each Network Scenario.


Why should your network attachment conditions determine who you can = talk to?

--001a11349882e979090505e30d13-- From nobody Mon Oct 20 17:40:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9741ACE5A for ; Mon, 20 Oct 2014 17:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7JFFRr1ENrb for ; Mon, 20 Oct 2014 17:40:37 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8361A1A62 for ; Mon, 20 Oct 2014 17:40:36 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id ar1so170006iec.10 for ; Mon, 20 Oct 2014 17:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5HKwxJ7GwKKIlneDI8tY+JUJQFJas+AU0MQ2ZNNhRZQ=; b=iv4YOMM+/2xIy0H2iIvgOflTgkR7Xr9qfzcJ19qCaIC9NkcRc32NyYZMu1QyJovHqi z5mCSr6bmMVPAFMFaFuGvt6g8N8e72Kcc9SQFv3ZJzEPEJqAUBSGZQ5g8q9MzHhr6qop yM8073LsCSvPH3uCCrkzZNav6HOkH65dPUS/hwwK21DZLhm6hAGgZSX93iXL1bQsOigq zqhaPas9wN5Zbp4hP8BkZ5G6gDn5OcTtbt7J1NDyVr6CdbbXFQN2WF1D4vEA0VComOkr DgSwhnQuARUtgsWwl4Ip3/Gpv/tGgWFU2/BpRPXjsepEcIOaMTGXWgE9oPCY+qHR3E3L tSCw== X-Received: by 10.42.49.8 with SMTP id u8mr29692911icf.39.1413852036150; Mon, 20 Oct 2014 17:40:36 -0700 (PDT) Received: from [192.168.1.113] (71-94-170-52.dhcp.knwc.wa.charter.com. [71.94.170.52]) by mx.google.com with ESMTPSA id n84sm5332941ioe.19.2014.10.20.17.40.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 17:40:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12A405) In-Reply-To: Date: Mon, 20 Oct 2014 17:40:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7025EA89-75F4-455A-AD90-8C5C5EFD4D5B@gmail.com> References: <949EF20990823C4C85C18D59AA11AD8B2627F1@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: rtcweb@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sxx6YApNHDTXin0p9FR7Nhf3TPQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 00:40:38 -0000 On Oct 20, 2014, at 3:29 PM, Justin Uberti wrote: >=20 > An astute observer might take note of the fact that our inability to close= the door on H.264 is providing an opportunity to other royalty-bearing code= cs that want to join the party. [BA] IETF WG Chairs have the ability to avoid revisiting previously settled i= ssues (e.g. Audio codecs) or unsettled ones (e.g. Video codecs). =20 BTW, I've had difficulty verifying the assertion that "AMR codecs are access= ible via the hardware without additional fees". There may be an SDK availabl= e, but my understanding is that this requires a licensing fee above and beyo= nd the fee required to license AMR codecs in Voice over LTE. In other words,= not only is the codec royalty bearing, but access to it for a purpose other= than VoLTE requires additional licensing fees. If this is wrong, please po= int me to the web page for the appropriate license-free SDKs.= From nobody Mon Oct 20 21:38:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8C71AD03A for ; Mon, 20 Oct 2014 21:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZLBw606-m92 for ; Mon, 20 Oct 2014 21:38:08 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D17A1AD007 for ; Mon, 20 Oct 2014 21:38:08 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id fb4so8881382wid.6 for ; Mon, 20 Oct 2014 21:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=tNirIP63NIkTMpDpiezDGwyDbD20MCbJ2uDXpGTIPsc=; b=CQyYPKGJoJt/7Vzsiy9octEDBjfdhgb9AsxuyxUpD+slG0b5QH+6dL7n2FQg8yGmXt HbEo5U2J/fInjAEHP3glUhL4+RX4FceAZyKlG/NmEeez1f9OyTnZ2zOOhJMPEuGbfHNK Ic6FWp26T1s2vFZWb9173AKnizNVQNKJYREwl547cKQ/+JEgefLTRsWLeugq7I57HaFw 276TpPtbuTterpIYVOUcYCPypj1E3uVhCV16lDl7D4p6VfDBL5t6qrAoUOWLMJ2TVO+X i2fnGF43IisaHE6XO3Yc/UXQwi2iDNMtTso64keAB71dw87CyPhwE1X+23hVxusjtNRP hPbA== X-Received: by 10.194.92.82 with SMTP id ck18mr38406947wjb.103.1413866286892; Mon, 20 Oct 2014 21:38:06 -0700 (PDT) Received: from [100.66.189.202] (94.212-142-204.dynamic.clientes.euskaltel.es. [212.142.204.94]) by mx.google.com with ESMTPSA id bj7sm13983190wjc.33.2014.10.20.21.37.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 21:38:06 -0700 (PDT) References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-BCD675B3-E3A8-4B7E-A386-344B4B2072AE Content-Transfer-Encoding: 7bit Message-Id: <5B0D7209-0BB5-479D-AE25-D6CE2D41A444@gmail.com> X-Mailer: iPhone Mail (11D201) From: Victor Pascual Date: Tue, 21 Oct 2014 06:37:45 +0200 To: Roman Shpount Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ztN8eiih5ftW8QwefL1FGIED2LQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 04:38:13 -0000 --Apple-Mail-BCD675B3-E3A8-4B7E-A386-344B4B2072AE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sounds like only consensus so far is we agree to disagree > On Oct 21, 2014, at 12:46 AM, Roman Shpount wrote: >=20 > Unless H.264 became royalty free or royalty free profile for H.264 is deve= loped (and I am talking about ability to include any implementation of this H= .264 profile into any project without paying royalties, not linking to somet= hing the end user must download), H.264 would not be acceptable to me as an= MTI. All the other news updates regarding H.264 are irrelevant. I would ass= ume most open source developer or smaller software developers would share my= opinion. >=20 > Settled law suits regarding VP8 also do not provide a significant change r= egarding video MTI. >=20 > There is nothing here to discuss except that we all want video MTI, but we= cannot agree on one. Why waste time on this? >=20 > _____________ > Roman Shpount >=20 >> On Sun, Oct 19, 2014 at 2:13 PM, Jonathan Rosenberg = wrote: >> @Alexandre - you say "Today, nothing has changed with respect to those tw= o items (even though providing open264 royalties and absorbing the license c= ost for some platforms might have been a set in the right direction). ". But= , as you say, the availability of Firefox with H264 is a change (previously i= t was not yet available); the fact that Cisco has in fact fronted the cost i= s a change (at the last meeting some were skeptical this would happen, but i= t has). The other big news was IOS8, which now enables apps to access H264 a= nd Apple pays the cost. Last time, the lack of a solution on IOS was a big d= eal. That is also now, no longer an issue. As such I think there are materia= l changes. >>=20 >>=20 >>> On Sun, Oct 19, 2014 at 12:13 PM, Alexandre GOUAILLARD wrote: >>> @jonathan, >>>=20 >>> while you are right and availability of 264 implementation or hardware a= cceleration has improved, it has never been reported as a problem in the pre= vious pool by anyone. The 264 royalties, and the VP8 IP risks were, AFAIR, t= he main reasons used by individuals to justify their positions. Today, nothi= ng has changed with respect to those two items (even though providing open26= 4 royalties and absorbing the license cost for some platforms might have bee= n a set in the right direction). This is why I think the conditions are not m= et for a consensus to be reached. >>>=20 >>> Alex. >>>=20 >>>=20 >>>> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba wrote: >>>> "And its one of the issues holding up wider adoption of the technology"= >>>>=20 >>>> [BA] Specifying an MTI encoder/decoder is not sufficient for interopera= bility. It is also necessary to specify the transport in enough detail to a= llow independent implementations that interoperate well enough to be usable i= n a wide variety of scenarios, including wireless networks where loss is com= monly experienced. =20 >>>>=20 >>>> We made the mistake of having an MTI discussion previously with not eno= ugh details on that subject, particularly with respect to H.264. draft-ietf-= rtcweb-video sections 4.2 - 4.4 remain sketchy at best. =20 >>>>=20 >>>> So if we are to have the discussion again, it should occur in the conte= xt of detailed specifications and interoperability reports. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg wrote: >>>>> I'm in favor of taking another run at this. >>>>>=20 >>>>> The working group has repeatedly said that an MTI codec is something w= e need to produce. And its one of the issues holding up wider adoption of th= e technology (not the only one for sure). >>>>>=20 >>>>> And things have changed since the last meeting, a year ago now (Novemb= er in Vancouver). Cisco's open264 plugin shipped and now just recently is in= tegrated into Firefox. iOS8 shipped with APIs for H264. There are other thin= gs worth noting. Will this change the minds of everyone? Surely not. Will it= sway enough for us to achieve rough consensus? Maybe. IMHO - worth finding o= ut. >>>>>=20 >>>>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD wrote: >>>>>> +1 to not having MTI codec discussion unless some progress has been m= ade on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that the= re was no change on the members position.=20 >>>>>>=20 >>>>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand wrote: >>>>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>>>>>> One thing we could do instead of wasting time on MTI is to actually= make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could= actually interoperate regardless of the codec. >>>>>>>=20 >>>>>>> The big argument for an MTI is actually the one stated in -overview:= It guards against interoperability failure. >>>>>>>=20 >>>>>>> I would like to have an ecosystem where one can field a box, connect= it to everything else, and run well for *some* level of "well" - and I woul= d prefer that ecosystem to be one where it's possible to field the box witho= ut making prior arrangements with anyone about licenses. >>>>>>>=20 >>>>>>> This argument hasn't changed one whit since last time we discussed i= t. And I don't see much movement on the specifics of the proposals either. >>>>>>>=20 >>>>>>> We'll have to interoperate well with the codecs we field. So using s= ome time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 is= n't finished either. There's one sentence that needs to be removed.) >>>>>>>=20 >>>>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd= prefer to re-discuss based on the knowledge that some significant players h= ave actually changed their minds. >>>>>>>=20 >>>>>>> At the moment, I don't see signs that any of the poll respondents ha= ve said "I have changed my mind". >>>>>>>=20 >>>>>>> Harald >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson wrote: >>>>>>>>>=20 >>>>>>>>>> On 16 October 2014 14:17, Matthew Kaufman wr= ote: >>>>>>>>>> And that's because something substantive has changed, or simply b= ecause >>>>>>>>>> wasting the WG time on this again is more entertaining than actua= lly >>>>>>>>>> finishing a specification that can be independently implemented b= y all >>>>>>>>>> browser vendors? (A specification that we are nowhere near having= , as far as >>>>>>>>>> I can tell) >>>>>>>>> Personally, I've found the reprieve from this fight refreshing. A= nd >>>>>>>>> it would appear that we've made some real progress as a result. I= 'd >>>>>>>>> suggest that if we don't have new information, we continue to spen= d >>>>>>>>> our time productively. If we can't find topics to occupy our meet= ing >>>>>>>>> agenda time, then maybe we can free an agenda slot. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Alex. Gouaillard, PhD, PhD, MBA >>>>>> ---------------------------------------------------------------------= --------------- >>>>>> CTO - Temasys Communications, S'pore / Mountain View >>>>>> President - CoSMo Software, Cambridge, MA >>>>>> ---------------------------------------------------------------------= --------------- >>>>>> sg.linkedin.com/agouaillard >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Jonathan Rosenberg, Ph.D. >>>>> jdrosen@jdrosen.net >>>>> http://www.jdrosen.net >>>>>=20 >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>>=20 >>>=20 >>> --=20 >>> Alex. Gouaillard, PhD, PhD, MBA >>> ------------------------------------------------------------------------= ------------ >>> CTO - Temasys Communications, S'pore / Mountain View >>> President - CoSMo Software, Cambridge, MA >>> ------------------------------------------------------------------------= ------------ >>> sg.linkedin.com/agouaillard >>=20 >>=20 >>=20 >> --=20 >> Jonathan Rosenberg, Ph.D. >> jdrosen@jdrosen.net >> http://www.jdrosen.net >>=20 >> _______________________________________________ >> 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 --Apple-Mail-BCD675B3-E3A8-4B7E-A386-344B4B2072AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sounds like only consensus so far is w= e agree to disagree

On Oct 21, 2014, at 12:46 AM, Roman Sh= pount <roman@telurix.com> wro= te:

Unless H.26= 4 became royalty free or royalty free profile for H.264 is developed (and I a= m talking about ability to include any implementation of this H.264 profile i= nto any project without paying royalties, not linking to something the end u= ser must  download), H.264 would not be acceptable to me as an MTI. All= the other news updates regarding H.264 are irrelevant. I would assume most o= pen source developer or smaller software developers would share my opinion.<= div>
Settled law suits regarding VP8 also do not provide a sig= nificant change regarding video MTI.

There is nothi= ng here to discuss except that we all want video MTI, but we cannot agree on= one. Why waste time on this?

_____________
Roman Shpount

On Sun, Oct 19, 2014 at 2:13 PM, Jonathan Ros= enberg <jdrosen@jdrosen.net> wrote:
@Alexandre - you say "Today, nothing has changed with respect to th= ose two items (even though providing open264 royalties and absorbing the lic= ense cost for some platforms might have been a set in the right direction).&= nbsp;". But, as you say, the availability of Firefox with H264 is a change (= previously it was not yet available); the fact that Cisco has in fact fronte= d the cost is a change (at the last meeting some were skeptical this would h= appen, but it has). The other big news was IOS8, which now enables apps to a= ccess H264 and Apple pays the cost. Last time, the lack of a solution on IOS= was a big deal. That is also now, no longer an issue. As such I think there= are material changes.


On Sun, Oct 1= 9, 2014 at 12:13 PM, Alexandre GOUAILLARD <agouaillard@gmail.com>= wrote:
@jonathan,<= div>
while you are right and availability of 264 implementatio= n or hardware acceleration has improved, it has never been reported as a pro= blem in the previous pool by anyone. The 264 royalties, and the VP8 IP risks= were, AFAIR, the main reasons used by individuals to justify their position= s. Today, nothing has changed with respect to those two items (even though p= roviding open264 royalties and absorbing the license cost for some platforms= might have been a set in the right direction). This is why I think the cond= itions are not met for a consensus to be reached.

A= lex.


On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
"And its one of the issues holding up wider adop= tion of the technology"

[BA] Specifying an MTI enc= oder/decoder is not sufficient for interoperability.  It is also necess= ary to specify the transport in enough detail to allow independent implement= ations that interoperate well enough to be usable in a wide variety of scena= rios, including wireless networks where loss is commonly experienced.  =

We made the mistake of having an MTI discussion pr= eviously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. &= nbsp;

So if we are to have the discussion again, it= should occur in the context of detailed specifications and interoperability= reports.

 

 

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <<= a href=3D"mailto:jdrosen@jdrosen.net" target=3D"_blank">jdrosen@jdrosen.net<= /a>> wrote:
I'm i= n favor of taking another run at this.

The working group h= as repeatedly said that an MTI codec is something we need to produce. And it= s one of the issues holding up wider adoption of the technology (not the onl= y one for sure).

And things have changed since the l= ast meeting, a year ago now (November in Vancouver). Cisco's open264 plugin s= hipped and now just recently is integrated into Firefox. iOS8 shipped with A= PIs for H264. There are other things worth noting. Will this change the mind= s of everyone? Surely not. Will it sway enough for us to achieve rough conse= nsus? Maybe. IMHO - worth finding out.

On Sat, Oct 18, 2014 at 5:08 PM, A= lexandre GOUAILLARD <agouaillard@gmail.com> wrote:
+1 to not having MTI codec discus= sion unless some progress has been made on VP8 at MPEG. Any news on tha= t? I'm sharing harald's  feeling that there was no change on the member= s position. 

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <harald@a= lvestrand.no> wrote:
On= 10/17/2014 12:02 AM, Bernard Aboba wrote:
One thing we could do instead of wasting time on MTI is to actually make pro= gress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually= interoperate regardless of the codec.

 The big argument for an MTI is actually the one stated in -overview: It guar= ds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to e= verything else, and run well for *some* level of "well" - and I would prefer= that ecosystem to be one where it's possible to field the box without makin= g prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. And I= don't see much movement on the specifics of the proposals either.

We'll have to interoperate well with the codecs we field. So using some time= to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't fini= shed either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer t= o re-discuss based on the knowledge that some significant players have actua= lly changed their minds.

At the moment, I don't see signs that any of the poll respondents have said "= I have changed my mind".

Harald






On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far as=
I can tell)
Personally, I've found the reprieve from this fight refreshing.  And it would appear that we've made some real progress as a result.  I'd suggest that if we don't have new information, we continue to spend
our time productively.  If we can't find topics to occupy our meeting agenda time, then maybe we can free an agenda slot.

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

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



--
Alex. Gouaillard, P= hD, PhD, MBA
-----------------------------------------------------------= -------------------------
CTO - Temasys Communications, S'pore / M= ountain View
President - CoSMo Software, Cambridge, MA
-= ----------------------------------------------------------------------------= -------


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




--

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





--
<= div dir=3D"ltr">Alex. Gouaillard, PhD, PhD, MBA
------------------------= ------------------------------------------------------------
CTO -= Temasys Communications, S'pore / Mountain View
President - CoSMo S= oftware, Cambridge, MA
-------------------------------------------= -----------------------------------------



--
<= div dir=3D"ltr">Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtcweb


____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-BCD675B3-E3A8-4B7E-A386-344B4B2072AE-- From nobody Mon Oct 20 22:55:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E211ACE70 for ; Mon, 20 Oct 2014 22:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpdb6eiZi_2c for ; Mon, 20 Oct 2014 22:55:16 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4188D1AD040 for ; Mon, 20 Oct 2014 22:55:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0C0EB7C0ADB; Tue, 21 Oct 2014 07:55:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAHn2A4BMn-M; Tue, 21 Oct 2014 07:55:10 +0200 (CEST) Received: from [10.121.43.50] (65.129-14-84.ripe.coltfrance.com [84.14.129.65]) by mork.alvestrand.no (Postfix) with ESMTPSA id BEC617C04EB; Tue, 21 Oct 2014 07:55:09 +0200 (CEST) Message-ID: <5445F53C.8000109@alvestrand.no> Date: Tue, 21 Oct 2014 07:55:08 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Justin Uberti , "DRAGE, Keith (Keith)" References: <949EF20990823C4C85C18D59AA11AD8B2627F1@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090605080105020700040302" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vt3SdCnrcPGsfstbDT9dZCPDkz8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 05:55:22 -0000 This is a multi-part message in MIME format. --------------090605080105020700040302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/21/2014 12:29 AM, Justin Uberti wrote: > From the subject "Plan for MTI video codec", I thought this discussion > was about video codecs, not AMR interop. All discussions branch, but I strongly recommend changing the subject line when changing the subject. The discussion is supposed to be managed by the WG chairs; since they have not spoken up on this thread at all, I must assume that they do not wish to constrain the discussion at this time. > > An astute observer might take note of the fact that our inability to > close the door on H.264 is providing an opportunity to other > royalty-bearing codecs that want to join the party. > > On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (Keith) > > wrote: > > The scenario where you might want to transcode the audio codec is > where you have wideband audio in both the OPUS and the AMR, and > you believe by transcoding you can achieve a wideband quality, > rather than falling back to G.711. And for interworking between > 3GPP devices that are not using webRTC, the audio will still be > AMR or AMR-WB or EVC, not OPUS. > > But audio transcoding is not particularly a concern for me. It is > trying where possible to avoid video transcoding. > > Keith > > ------------------------------------------------------------------------ > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org > ] *On Behalf Of *Andrew Allen > *Sent:* 20 October 2014 14:52 > *To:* chris.cavigioli@intel.com > ; harald@alvestrand.no > ; bernard.aboba@gmail.com > > > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > Chris > > What is the scenario that dictates the need for direct > transcoding between OPUS and AMR? > > All RTCweb clients MUST support OPUS so for Web browsers on > mobile LTE devices OPUS can be negotiated with non mobile > RTCweb devices end to end. > > My expectation is that for mobile devices the RTCweb client > will also have access to the embedded AMR codec so mobile > RTCweb devices can interoperate using AMR with non-RTCweb > enabled mobile IMS devices that support AMR. > > For interoperation between non mobile RTCweb devices and > mobile non RTCweb IMS devices the non mobile RTCweb device can > use G.711 to the transcoder for transcoding to AMR on the > other side. While not ideal this will be no worse than non > mobile RTCweb devices interoperating with circuit switched > only mobile devices which will be forced to interoperate via > the PSTN. > > As RTCweb becomes universal on mobile devices I expect that > support for OPUS will become native and mobile IMS devices > will also be able to use OPUS even when operating without the > use of the browser (i.e. in non RTCweb mode) for better > interoperation with non-mobile RTCweb devices. > > The lifetime of most mobile devices is 2 years or less so this > is likely to be mainly a short term transition issue only. > > Andrew > > *From*: Cavigioli, Chris [mailto:chris.cavigioli@intel.com > ] > *Sent*: Sunday, October 19, 2014 09:20 PM Eastern Standard Time > *To*: Harald Alvestrand >; Bernard Aboba > > > *Cc*: rtcweb@ietf.org > > > *Subject*: Re: [rtcweb] Plan for MTI video codec? > > > Harald said: > > “We made the mistake of having an MTI discussion previously > with not enough details on that subject…†> > > > We didn’t have quantitative data earlier for a data-driven > decision. Future Web – LTE interop is important. A group of > us in GSMA have been looking at WebRTC interop with LTE (where > 3GPP / GSMA defined IMS-based voice/video/messaging), > specifically looking at user experience impact of latency > introduced by added in-network transcoding. GSMA has approved > the whitepaper and it is being prepared for public distribution. > > > > WebRTC – LTE transcoding is now MANDATORY because of “WebRTC > Audio Codec and Processing Requirementsâ€. > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where > MTI audio codecs in WebRTC and in LTE are dissimilar. Thus, > REGARDLESS of the video codecs, there is already a significant > degradation imposed on Web – LTE links if only MTI codecs are > used. The only systems to avoid this are those which > implement OPTIONAL audio codecs to be transcoder-free with > LTE. The same can apply for video codecs. > > > > The GSMA whitepaper refers to: > > 1. Quantitative voice-over-LTE (VoLTE) delay limits were > agreed-to by 3GPP SA4 in August 2014. To paraphrase, > performance objectives for maximum VoLTE device delays in > error and jitter free conditions and AMR speech codec > operation, the sum of the UE delays in sending and receiving > directions (T_S + T_R ) should be ≤ 150ms. If this performance > objective cannot be met, the sum of the UE delays in sending > and receiving directions (T_S + T_R ) shall in any case be ≤ > 190ms. > > 2. OPUS – AMR transcoding adds an additional 211.5 ms > implementation-agnostic (T_S + T_R ) delay, including 40 ms > for jitter buffer and 40 ms for discontinuous reception (DRX). > > 3. To put these numbers in perspective, it is in general > desirable to minimize UE delays to ensure low enough > end-to-end delays and hence a good conversational experience. > Increasing delay causes people to double-talk making > conversations increasingly frustrating. Guidance to stay > below 400 ms maximum one-way delay is found in ITU-T > Recommendation G.114 and the computational E-model is in ITU-T > Recommendation G.107. > > > > This is a complex topic with many network factors in play. > LTE operators in 3GPP seek UE delays (T_S + T_R ) around 150 > ms. Adding OPUS – AMR transcoding in the network imposes an > additional 211.5 ms on top of that, just for audio. > Optionally using AMR in WebRTC, those 211.5 ms can be > eliminated, delivering a superior end-user experience. > > > > CONCLUSION: regardless of MTI codec choices in WebRTC, to > provide a good WebRTC – LTE interop experience, emerging > WebRTC systems must accommodate MTI codecs already deployed in > the LTE domain and in mobile operating systems, namely > AMR/AMR-WB and H.264. > > > > POSITION: To be clear, several Intel SoCs launched at MWC > this year for smartphones and tablets support both VP8 and > H.264 hardware encode and decode – so Intel is codec-neutral > in this MTI debate. Additionally, Intel has high-performance > solutions for transcoding. However, we wish to inform the > industry, with quantitative data, about impact to end-user > experience of mandating such transcoding so IETF can make a > data-driven decision on video codecs as well as reflect on the > impact of already having mandated transcoding on the audio side. > > > > Chris Cavigioli > > Intel Corp, System Architecture and Planning, > Video/Multimedia, Mobile and Communications Group (MCG) > > +1 (415) 254-4545 mobile > > +1 (408) 653-8348 desk > > +1 (408) 884-2400 fax > > This e-mail may contain confidential and privileged material > for the sole use of the intended recipient(s). Any review or > distribution by others is strictly prohibited. If you are not > the intended recipient, please contact the sender and delete > all copies. > > > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org > ] *On Behalf Of *Bernard Aboba > *Sent:* Sunday, October 19, 2014 2:29 PM > *To:* Harald Alvestrand > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Harald said: > > > > "Bernard, > > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox > and Chrome, and usage of various mechanisms for congestion > control and repair of packet loss being applied in live services. > > So it can't be all bad....." > > > > [BA] I agree that the lack of interoperability is largely > "codec independent": that is, implementations based on > different mechanisms for congestion control, repair, etc. will > exhibit interoperability problems, regardless of the codec > chosen. The real test for RTCWEB will be to move beyond > "interoperability of implementations sharing source code" to > "interoperability of independent implementations, based on > open standards". > > > > On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand > > wrote: > > On 10/19/2014 05:43 PM, Bernard Aboba wrote: > > "And its one of the issues holding up wider adoption of > the technology" > > > > [BA] Specifying an MTI encoder/decoder is not sufficient > for interoperability. It is also necessary to specify the > transport in enough detail to allow independent > implementations that interoperate well enough to be usable > in a wide variety of scenarios, including wireless > networks where loss is commonly experienced. > > > Bernard, > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox > and Chrome, and usage of various mechanisms for congestion > control and repair of packet loss being applied in live services. > > So it can't be all bad..... > > > > > > > We made the mistake of having an MTI discussion previously > with not enough details on that subject, particularly with > respect to H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 > remain sketchy at best. > > > > So if we are to have the discussion again, it should occur in > the context of detailed specifications and interoperability > reports. > > > > > > > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > > wrote: > > I'm in favor of taking another run at this. > > > > The working group has repeatedly said that an MTI codec is > something we need to produce. And its one of the issues > holding up wider adoption of the technology (not the only one > for sure). > > > > And things have changed since the last meeting, a year ago now > (November in Vancouver). Cisco's open264 plugin shipped and > now just recently is integrated into Firefox. iOS8 shipped > with APIs for H264. There are other things worth noting. Will > this change the minds of everyone? Surely not. Will it sway > enough for us to achieve rough consensus? Maybe. IMHO - worth > finding out. > > > > On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD > > wrote: > > +1 to not having MTI codec discussion unless some progress has > been made on VP8 at MPEG. Any news on that? I'm sharing > harald's feeling that there was no change on the members > position. > > > > On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > > wrote: > > On 10/17/2014 12:02 AM, Bernard Aboba wrote: > > One thing we could do instead of wasting time on MTI is to > actually make progress on Sections 4.2 - 4.4 of > draft-IETF-RTCWEB-video, so we could actually interoperate > regardless of the codec. > > > The big argument for an MTI is actually the one stated in > -overview: It guards against interoperability failure. > > I would like to have an ecosystem where one can field a box, > connect it to everything else, and run well for *some* level > of "well" - and I would prefer that ecosystem to be one where > it's possible to field the box without making prior > arrangements with anyone about licenses. > > This argument hasn't changed one whit since last time we > discussed it. And I don't see much movement on the specifics > of the proposals either. > > We'll have to interoperate well with the codecs we field. So > using some time to discuss draft-ietf-rtcweb-video seems to > make sense. (And 4.1 isn't finished either. There's one > sentence that needs to be removed.) > > I wouldn't say I'd be happy to not discuss this in Honolulu. > But I'd prefer to re-discuss based on the knowledge that some > significant players have actually changed their minds. > > At the moment, I don't see signs that any of the poll > respondents have said "I have changed my mind". > > Harald > > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > > > wrote: > > On 16 October 2014 14:17, Matthew Kaufman > wrote: > And that's because something substantive has changed, or > simply because > wasting the WG time on this again is more entertaining than > actually > finishing a specification that can be independently > implemented by all > browser vendors? (A specification that we are nowhere near > having, as far as > I can tell) > > Personally, I've found the reprieve from this fight > refreshing. And > it would appear that we've made some real progress as a > result. I'd > suggest that if we don't have new information, we continue to > spend > our time productively. If we can't find topics to occupy our > meeting > agenda time, then maybe we can free an agenda slot. > > _______________________________________________ > 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 > > > > > > -- > > Alex. Gouaillard, PhD, PhD, MBA > > ------------------------------------------------------------------------------------ > > CTO - Temasys Communications, S'pore / Mountain View > > President - CoSMo Software, Cambridge, MA > > ------------------------------------------------------------------------------------ > > sg.linkedin.com/agouaillard > > · > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > 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 > > > > -- > > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > 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 > > -- Surveillance is pervasive. Go Dark. --------------090605080105020700040302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/21/2014 12:29 AM, Justin Uberti wrote:
From the subject "Plan for MTI video codec", I thought this discussion was about video codecs, not AMR interop.

All discussions branch, but I strongly recommend changing the subject line when changing the subject.

The discussion is supposed to be managed by the WG chairs; since they have not spoken up on this thread at all, I must assume that they do not wish to constrain the discussion at this time.


An astute observer might take note of the fact that our inability to close the door on H.264 is providing an opportunity to other royalty-bearing codecs that want to join the party.

On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
The scenario where you might want to transcode the audio codec is where you have wideband audio in both the OPUS and the AMR, and you believe by transcoding you can achieve a wideband quality, rather than falling back to G.711. And for interworking between 3GPP devices that are not using webRTC, the audio will still be AMR or AMR-WB or EVC, not OPUS.
 
But audio transcoding is not particularly a concern for me. It is trying where possible to avoid video transcoding.
 
Keith

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen
Sent: 20 October 2014 14:52
To: chris.cavigioli@intel.com; harald@alvestrand.no; bernard.aboba@gmail.com

Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan for MTI video codec?


Chris

What is the scenario that dictates the need for direct transcoding between OPUS and AMR?

All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE devices OPUS can be negotiated with non mobile RTCweb devices end to end.

My expectation is that for mobile devices the RTCweb client will also have access to the embedded AMR codec so mobile RTCweb devices can interoperate using AMR with non-RTCweb enabled mobile IMS devices that support AMR.

For interoperation between non mobile RTCweb devices and mobile non RTCweb IMS devices the non mobile RTCweb device can use G.711 to the transcoder for transcoding to AMR on the other side. While not ideal this will be no worse than non mobile RTCweb devices interoperating with circuit switched only mobile devices which will be forced to interoperate via the PSTN.

As RTCweb becomes universal on mobile devices I expect that support for OPUS will become native and mobile IMS devices will also be able to use OPUS even when operating without the use of the browser (i.e. in non RTCweb mode) for better interoperation with non-mobile RTCweb devices.

The lifetime of most mobile devices is 2 years or less so this is likely to be mainly a short term transition issue only.

Andrew
 
From: Cavigioli, Chris [mailto:chris.cavigioli@intel.com]
Sent: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
To: Harald Alvestrand <harald@alvestrand.no>; Bernard Aboba <bernard.aboba@gmail.com>
Cc: rtcweb@ietf.org <rtcweb@ietf.org>
Subject: Re: [rtcweb] Plan for MTI video codec?
 

Harald said: 

“We made the mistake of having an MTI discussion previously with not enough details on that subject…â€

 

We didn’t have quantitative data earlier for a data-driven decision.  Future Web – LTE interop is important.  A group of us in GSMA have been looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messaging), specifically looking at user experience impact of latency introduced by added in-network transcoding.  GSMA has approved the whitepaper and it is being prepared for public distribution. 

 

WebRTC – LTE transcoding is now MANDATORY because of “WebRTC Audio Codec and Processing Requirementsâ€. http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio codecs in WebRTC and in LTE are dissimilar.  Thus, REGARDLESS of the video codecs, there is already a significant degradation imposed on Web – LTE links if only MTI codecs are used.  The only systems to avoid this are those which implement OPTIONAL audio codecs to be transcoder-free with LTE.  The same can apply for video codecs.

 

The GSMA whitepaper refers to:

1.     Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by 3GPP SA4 in August 2014.  To paraphrase, performance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec operation, the sum of the UE delays in sending and receiving directions (TS + TR) should be ≤ 150ms. If this performance objective cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR) shall in any case be ≤ 190ms.

2.     OPUS – AMR transcoding adds an additional 211.5 ms implementation-agnostic (TS + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.     To put these numbers in perspective, it is in general desirable to minimize UE delays to ensure low enough end-to-end delays and hence a good conversational experience.  Increasing delay causes people to double-talk making conversations increasingly frustrating.  Guidance to stay below 400 ms maximum one-way delay is found in ITU-T Recommendation G.114 and the computational E-model is in ITU-T Recommendation G.107.

 

This is a complex topic with many network factors in play.  LTE operators in 3GPP seek UE delays (TS + TR) around 150 ms.  Adding OPUS – AMR transcoding in the network imposes an additional 211.5 ms on top of that, just for audio.  Optionally using AMR in WebRTC, those 211.5 ms can be eliminated, delivering a superior end-user experience. 

 

CONCLUSION:  regardless of MTI codec choices in WebRTC, to provide a good WebRTC – LTE interop experience, emerging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely AMR/AMR-WB and H.264.

 

POSITION:  To be clear, several Intel SoCs launched at MWC this year for smartphones and tablets support both VP8 and H.264 hardware encode and decode – so Intel is codec-neutral in this MTI debate.  Additionally, Intel has high-performance solutions for transcoding.  However, we wish to inform the industry, with quantitative data, about impact to end-user experience of mandating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impact of already having mandated transcoding on the audio side.

 

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group (MCG)

+1 (415) 254-4545 mobile

+1 (408) 653-8348 desk

+1 (408) 884-2400 fax

This e-mail may contain confidential and privileged material for the sole use of the intended recipient(s).  Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan for MTI video codec?

 

Harald said: 

 

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, and usage of various mechanisms for congestion control and repair of packet loss being applied in live services.

So it can't be all bad....."

 

[BA]  I agree that the lack of interoperability is largely "codec independent":   that is, implementations based on different mechanisms for congestion control, repair, etc. will exhibit interoperability problems, regardless of the codec chosen.   The real test for RTCWEB will be to move beyond "interoperability of implementations sharing source code"  to "interoperability of independent implementations, based on open standards".   

 

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand <harald@alvestrand.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:

"And its one of the issues holding up wider adoption of the technology"

 

[BA] Specifying an MTI encoder/decoder is not sufficient for interoperability.  It is also necessary to specify the transport in enough detail to allow independent implementations that interoperate well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienced. 


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, and usage of various mechanisms for congestion control and repair of packet loss being applied in live services.

So it can't be all bad.....




 

We made the mistake of having an MTI discussion previously with not enough details on that subject, particularly with respect to H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.  

 

So if we are to have the discussion again, it should occur in the context of detailed specifications and interoperability reports.

 

 

 

 

 

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:

I'm in favor of taking another run at this.

 

The working group has repeatedly said that an MTI codec is something we need to produce. And its one of the issues holding up wider adoption of the technology (not the only one for sure).

 

And things have changed since the last meeting, a year ago now (November in Vancouver). Cisco's open264 plugin shipped and now just recently is integrated into Firefox. iOS8 shipped with APIs for H264. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough for us to achieve rough consensus? Maybe. IMHO - worth finding out.

 

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:

+1 to not having MTI codec discussion unless some progress has been made on VP8 at MPEG. Any news on that? I'm sharing harald's  feeling that there was no change on the members position. 

 

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand <harald@alvestrand.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:

One thing we could do instead of wasting time on MTI is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actually interoperate regardless of the codec.


The big argument for an MTI is actually the one stated in -overview: It guards against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to everything else, and run well for *some* level of "well" - and I would prefer that ecosystem to be one where it's possible to field the box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. And I don't see much movement on the specifics of the proposals either.

We'll have to interoperate well with the codecs we field. So using some time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't finished either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer to re-discuss based on the knowledge that some significant players have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have said "I have changed my mind".

Harald





On Oct 16, 2014, at 2:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at> wrote:
And that's because something substantive has changed, or simply because
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far as
I can tell)

Personally, I've found the reprieve from this fight refreshing.  And
it would appear that we've made some real progress as a result.  I'd
suggest that if we don't have new information, we continue to spend
our time productively.  If we can't find topics to occupy our meeting
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



 

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

·          


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



 

--

Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net


_______________________________________________
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

 

-- 
Surveillance is pervasive. Go Dark.


_______________________________________________
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




-- 
Surveillance is pervasive. Go Dark.
--------------090605080105020700040302-- From nobody Tue Oct 21 00:26:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880A81AD09C for ; Tue, 21 Oct 2014 00:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ApEWCaTwnyL for ; Tue, 21 Oct 2014 00:25:57 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A64611AD09A for ; Tue, 21 Oct 2014 00:25:55 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 2953B93C1AF; Tue, 21 Oct 2014 07:24:49 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 21 Oct 2014 09:25:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <633DB431-D3DA-4294-A926-33E30D22F3D6@edvina.net> References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wxbJ8NcvVs-d-wyc29tZvJIH4cM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 07:25:59 -0000 On 21 Oct 2014, at 00:50, I=F1aki Baz Castillo wrote: > 2014-10-21 0:46 GMT+02:00 Roman Shpount : >> Unless H.264 became royalty free or royalty free profile for H.264 is >> developed (and I am talking about ability to include any = implementation of >> this H.264 profile into any project without paying royalties, not = linking to >> something the end user must download), H.264 would not be acceptable = to me >> as an MTI. All the other news updates regarding H.264 are irrelevant. = I >> would assume most open source developer or smaller software = developers would >> share my opinion. >=20 > +1 +pi /O= From nobody Tue Oct 21 00:35:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6D31AD08F for ; Tue, 21 Oct 2014 00:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA544vjx7PEO for ; Tue, 21 Oct 2014 00:35:42 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0069.outbound.protection.outlook.com [65.55.169.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CBF1AD080 for ; Tue, 21 Oct 2014 00:35:42 -0700 (PDT) Received: from CY1PR0501MB1577.namprd05.prod.outlook.com (25.161.161.151) by CY1PR0501MB1498.namprd05.prod.outlook.com (25.160.149.147) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 07:35:41 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1577.namprd05.prod.outlook.com (25.161.161.151) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 07:35:40 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1054.004; Tue, 21 Oct 2014 07:35:40 +0000 From: "Wyss, Felix" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYIAADzmAgAAmfQCAAFWsAIAAG4cggAEmdgCAADW+gIAAINaAgAAXDgCAAA+BgIAAIqQAgABN64CAAPELcIABF92AgATZ34CAAJFUwIABmHeAgAP3gnA= Date: Tue, 21 Oct 2014 07:35:39 +0000 Message-ID: <514191b6e7764d30be7ea17d324d8739@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> <543CD1CD.3000001@alvestrand.no> <5440E38F.9070809@jesup.org> <5442B41D.6040307@jesup.org> In-Reply-To: <5442B41D.6040307@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.147.12.61] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1577;UriScan:; inin-custom: wl-d x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(199003)(189002)(93886004)(85306004)(40100003)(50986999)(122556002)(86362001)(54356999)(76176999)(2656002)(87936001)(92566001)(101416001)(31966008)(85852003)(74316001)(4396001)(95666004)(99286002)(97736003)(77096002)(21056001)(33646002)(76576001)(2501002)(107046002)(20776003)(64706001)(120916001)(230783001)(99396003)(107886001)(108616004)(46102003)(80022003)(76482002)(66066001)(105586002)(106356001)(106116001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1577; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1498; X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/C9jgpEovE9rPJYUxWJ9dGMWpVPs Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 07:35:51 -0000 > Per above, if it's simply asking the application for an offer, then > forwarding it, there's no issue: the offer is a true offer, you never > have to "convert" an SDP offer into an answer or vice versa, and the > offer will be actpass and roles will be consistent (assuming the > middlebox isn't trying to intercept/sniff the decrypted DataChannel data)= . You are right, that case will work. I was thinking that the middlebox coul= d treat the first leg as more independent and not having to wait for the an= swer on the second leg for faster connection establishment. =20 > So, if the middle box uses sip-style "empty offers" (ask the app to make > an offer), then I think there are no issues with DTLS role. If it tries > to avoid the 3-way handshake style, or work with apps that don't > understand it then there'd be an issue (but in webrtc signaling isn't > specified, so the middlebox MUST be designed to be compatible with the > signaling used by the apps). >=20 > Also, if the middlebox acts as an "answerer-in-the-middle", DTLS roles > should work: > A->middlebox offer, B->middlebox offer, middlebox->A answer, > middlebox->B answer (where the answers are derived from the offer on the > other side). This again requires that the two Offers be safely > transformable by the middlebox into answers without a renegotiation. The > middlebox would select the roles in the answers to be complimentary. The "empty offer" approach makes more sense in the SIP world because endpoi= nts are rather heterogeneous in their codec support. It thus allows the mi= ddlebox more control over codec selection by being the answerer. One of th= e big advantages of WebRTC and its mandatory-to-implement codec is that it = safe to simply offer Opus and be done with it. Having to resort to the "an= swerer in the middle" approach just so the DTLS roles can be picked is actu= ally another good example of how the DTLS role abstraction leak has uninten= ded consequences and is bad. =20 > I disagree that role won't work if the middlebox is just forwarding > offers and answers - that's what every WebRTC signaling server is doing > today. However, as I think you implied, you're also terminating DTLS > but forwarding SCTP (and media). This a) implies packet-relay; b) > implicit decryption of all media at the server (NOTE this is a > security/privacy/MITM issue). Yes, that's the intended use-case: The middlebox is a trusted man-in-the-mi= ddle. In order to record and/or perform analytics on the media flowing thr= ough it, it obviously has to decrypt it. That can only be done by terminat= ing DTLS (and decrypting/re-encrypting SRTP.) =20 > Also, assuming some bits of my analysis are incorrect, or there are edge > cases we care about we don't handle (the non-SIP-like start-in-middle > case), then (and only then) as a working group, we need to decide if > this is a usecase we support. Obviously B2BUA's (which this > more-or-less is) are always possible, at varying levels of ease. The > question (partly) is should the protocol be designed to ease the use of > a B2BUA with datachannels *assuming* it doesn't work per above. Without inband ID negotiation or an SDP parameter, an "offerer in the middl= e" middlebox or B2BUA won't be possible. I think having the flexibility to= use either/any scenario is highly desirable.=20 > >> An SDP parameter would > >> allow a middlebox to specify to the endpoints compatible > (complementary) > >> values; however from a DataChannels perspective, this is almost the sa= me > as > >> external negotiation if the middlebox and applications are 'matched'. > > If in-band negotiation and collision resolution is not an option, addin= g an > SDP attribute would be my second choice. If it's not present, use > offerer/answerer role. >=20 > If we *cannot* safely use DTLS role for middlebox cases, and care, then > we should allow SDP to override the DTLS role (not use the SDP offer > state as the base). If an offerer doesn't specify even/odd in the SDP, > but the answer does specify, then the offerer must use the SDP of the > answerer to select even/odd (i.e. SDP overrides role). Having an SDP parameter that overrides the DTLS role instead of the offer/a= nswer role is fine by me. As long as there is a way to override ID selecti= on instead of using the DTLS role. I nevertheless feel an in-band solution= that doesn't depend on signaling or lower-level transport state would be b= etter as it minimizes dependencies and localizes the complexity in DCEP. --Felix From nobody Tue Oct 21 01:00:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063871AD09C for ; Tue, 21 Oct 2014 01:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvTJhTw5klJq for ; Tue, 21 Oct 2014 01:00:45 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26A21AD0A8 for ; Tue, 21 Oct 2014 01:00:44 -0700 (PDT) Received: (qmail 2034 invoked from network); 21 Oct 2014 08:00:42 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 1359 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 21 Oct 2014 08:00:42 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 52D3518A108D; Tue, 21 Oct 2014 09:00:43 +0100 (BST) Received: from [192.168.157.34] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 1517818A037F; Tue, 21 Oct 2014 09:00:43 +0100 (BST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: <514191b6e7764d30be7ea17d324d8739@CY1PR0501MB1579.namprd05.prod.outlook.com> Date: Tue, 21 Oct 2014 09:00:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> <543CD1CD.3000001@alvestrand.no> <5440E38F.9070809@jesup.org> <5442B41D.6040307@jesup.org> <514191b6e7 764d30be7ea17d324d8739@CY1PR0501MB1579.namprd05.prod.outlook.com> To: "Wyss, Felix" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cefCzHjJhdrBjkUZVoJgCV6chls Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 08:00:47 -0000 On 21 Oct 2014, at 08:35, Wyss, Felix wrote: >=20 >=20 >> I disagree that role won't work if the middlebox is just forwarding >> offers and answers - that's what every WebRTC signaling server is = doing >> today. However, as I think you implied, you're also terminating = DTLS >> but forwarding SCTP (and media). This a) implies packet-relay; b) >> implicit decryption of all media at the server (NOTE this is a >> security/privacy/MITM issue). >=20 > Yes, that's the intended use-case: The middlebox is a trusted = man-in-the-middle. In order to record and/or perform analytics on the = media flowing through it, it obviously has to decrypt it. That can only = be done by terminating DTLS (and decrypting/re-encrypting SRTP.) =20 If the middle box is trusted, only interested in media and known about = by the application, then the application should create a separate=20 direct data channel only DTLS connection between the endpoints that = bypasses the middle box, with a small amount of extra application effort we remove the need for even more random extra SDP lines. Remember = these are programmable endpoints - not dumb SIP devices with fixed = behaviours. Unless the middle box is performing =91analytics=92 on the DC data too, = but that isn=92t the use-case you mentioned. Tim. From nobody Tue Oct 21 02:09:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C8B1A0149 for ; Tue, 21 Oct 2014 02:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-yjoDlXDwQE for ; Tue, 21 Oct 2014 02:09:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C521A016B for ; Tue, 21 Oct 2014 02:09:42 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B7E21BED8101D; Tue, 21 Oct 2014 09:09:37 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9L99YGP008775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 11:09:35 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 11:08:40 +0200 From: "DRAGE, Keith (Keith)" To: Justin Uberti Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP7LVH2AshmHfxg0SddD4axlD+Cpw6LYjQ Date: Tue, 21 Oct 2014 09:08:40 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B263123@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B2627F1@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B263123FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7WnmXDvj4H1bk-ENhLAYtXDSnF8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 09:09:52 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B263123FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable With respect to audio codecs I was replying to a question from the previous= message in the thread. But... The MTI discussion does not close the door on any codec, as any codec can b= e supported, just not mandatory to implement. Your argument to eliminate H.264 only applies if you can either eliminate i= nterworking with the rest of the world or you can persuade all those legacy= devices to remove H.264 and use something else, which in my view is totall= y impractical. MTI might persuade usage of that codec, but it will only do that if the MTI= codec actually supports end to end communication of the required video cap= abilities. Neither VP8 or H.264 fit all those requirements. Keith ________________________________ From: Justin Uberti [mailto:juberti@google.com] Sent: 20 October 2014 23:29 To: DRAGE, Keith (Keith) Cc: Andrew Allen; chris.cavigioli@intel.com; harald@alvestrand.no; bernard.= aboba@gmail.com; rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? >From the subject "Plan for MTI video codec", I thought this discussion was = about video codecs, not AMR interop. An astute observer might take note of the fact that our inability to close = the door on H.264 is providing an opportunity to other royalty-bearing code= cs that want to join the party. On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (Keith) > wrote: The scenario where you might want to transcode the audio codec is where you= have wideband audio in both the OPUS and the AMR, and you believe by trans= coding you can achieve a wideband quality, rather than falling back to G.71= 1. And for interworking between 3GPP devices that are not using webRTC, the= audio will still be AMR or AMR-WB or EVC, not OPUS. But audio transcoding is not particularly a concern for me. It is trying wh= ere possible to avoid video transcoding. Keith ________________________________ From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 20 October 2014 14:52 To: chris.cavigioli@intel.com; harald@alv= estrand.no; bernard.aboba@gmail.com Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? Chris What is the scenario that dictates the need for direct transcoding between = OPUS and AMR? All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE devi= ces OPUS can be negotiated with non mobile RTCweb devices end to end. My expectation is that for mobile devices the RTCweb client will also have = access to the embedded AMR codec so mobile RTCweb devices can interoperate = using AMR with non-RTCweb enabled mobile IMS devices that support AMR. For interoperation between non mobile RTCweb devices and mobile non RTCweb = IMS devices the non mobile RTCweb device can use G.711 to the transcoder fo= r transcoding to AMR on the other side. While not ideal this will be no wor= se than non mobile RTCweb devices interoperating with circuit switched only= mobile devices which will be forced to interoperate via the PSTN. As RTCweb becomes universal on mobile devices I expect that support for OPU= S will become native and mobile IMS devices will also be able to use OPUS e= ven when operating without the use of the browser (i.e. in non RTCweb mode)= for better interoperation with non-mobile RTCweb devices. The lifetime of most mobile devices is 2 years or less so this is likely to= be mainly a short term transition issue only. Andrew From: Cavigioli, Chris [mailto:chris.cavigioli@intel.com] Sent: Sunday, October 19, 2014 09:20 PM Eastern Standard Time To: Harald Alvestrand >; = Bernard Aboba > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Plan for MTI video codec? Harald said: "We made the mistake of having an MTI discussion previously with not enough= details on that subject..." We didn't have quantitative data earlier for a data-driven decision. Futur= e Web - LTE interop is important. A group of us in GSMA have been looking = at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video= /messaging), specifically looking at user experience impact of latency intr= oduced by added in-network transcoding. GSMA has approved the whitepaper a= nd it is being prepared for public distribution. WebRTC - LTE transcoding is now MANDATORY because of "WebRTC Audio Codec an= d Processing Requirements". http://tools.ietf.org/html/draft-ietf-rtcweb-au= dio-05, where MTI audio codecs in WebRTC and in LTE are dissimilar. Thus, = REGARDLESS of the video codecs, there is already a significant degradation = imposed on Web - LTE links if only MTI codecs are used. The only systems t= o avoid this are those which implement OPTIONAL audio codecs to be transcod= er-free with LTE. The same can apply for video codecs. The GSMA whitepaper refers to: 1. Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by 3= GPP SA4 in August 2014. To paraphrase, performance objectives for maximum = VoLTE device delays in error and jitter free conditions and AMR speech code= c operation, the sum of the UE delays in sending and receiving directions (= TS + TR) should be =98 150ms. If this performance objective cannot be met, = the sum of the UE delays in sending and receiving directions (TS + TR) shal= l in any case be =98 190ms. 2. OPUS - AMR transcoding adds an additional 211.5 ms implementation-ag= nostic (TS + TR) delay, including 40 ms for jitter buffer and 40 ms for dis= continuous reception (DRX). 3. To put these numbers in perspective, it is in general desirable to m= inimize UE delays to ensure low enough end-to-end delays and hence a good c= onversational experience. Increasing delay causes people to double-talk ma= king conversations increasingly frustrating. Guidance to stay below 400 ms= maximum one-way delay is found in ITU-T Recommendation G.114 and the compu= tational E-model is in ITU-T Recommendation G.107. This is a complex topic with many network factors in play. LTE operators i= n 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS - AMR transcodi= ng in the network imposes an additional 211.5 ms on top of that, just for a= udio. Optionally using AMR in WebRTC, those 211.5 ms can be eliminated, de= livering a superior end-user experience. CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a good W= ebRTC - LTE interop experience, emerging WebRTC systems must accommodate MT= I codecs already deployed in the LTE domain and in mobile operating systems= , namely AMR/AMR-WB and H.264. POSITION: To be clear, several Intel SoCs launched at MWC this year for sm= artphones and tablets support both VP8 and H.264 hardware encode and decode= - so Intel is codec-neutral in this MTI debate. Additionally, Intel has h= igh-performance solutions for transcoding. However, we wish to inform the = industry, with quantitative data, about impact to end-user experience of ma= ndating such transcoding so IETF can make a data-driven decision on video c= odecs as well as reflect on the impact of already having mandated transcodi= ng on the audio side. Chris Cavigioli Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and = Communications Group (MCG) +1 (415) 254-4545 mobile +1 (408) 653-8348 desk +1 (408) 884-2400 fax This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient(s). Any review or distribution by others is s= trictly prohibited. If you are not the intended recipient, please contact t= he sender and delete all copies. From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Sunday, October 19, 2014 2:29 PM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? Harald said: "Bernard, I think this is, to a large degree, codec independent. We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services. So it can't be all bad....." [BA] I agree that the lack of interoperability is largely "codec independe= nt": that is, implementations based on different mechanisms for congestio= n control, repair, etc. will exhibit interoperability problems, regardless = of the codec chosen. The real test for RTCWEB will be to move beyond "int= eroperability of implementations sharing source code" to "interoperability= of independent implementations, based on open standards". On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand > wrote: On 10/19/2014 05:43 PM, Bernard Aboba wrote: "And its one of the issues holding up wider adoption of the technology" [BA] Specifying an MTI encoder/decoder is not sufficient for interoperabili= ty. It is also necessary to specify the transport in enough detail to allo= w independent implementations that interoperate well enough to be usable in= a wide variety of scenarios, including wireless networks where loss is com= monly experienced. Bernard, I think this is, to a large degree, codec independent. We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services. So it can't be all bad..... We made the mistake of having an MTI discussion previously with not enough = details on that subject, particularly with respect to H.264. draft-ietf-rtc= web-video sections 4.2 - 4.4 remain sketchy at best. So if we are to have the discussion again, it should occur in the context o= f detailed specifications and interoperability reports. On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: I'm in favor of taking another run at this. The working group has repeatedly said that an MTI codec is something we nee= d to produce. And its one of the issues holding up wider adoption of the te= chnology (not the only one for sure). And things have changed since the last meeting, a year ago now (November in= Vancouver). Cisco's open264 plugin shipped and now just recently is integr= ated into Firefox. iOS8 shipped with APIs for H264. There are other things = worth noting. Will this change the minds of everyone? Surely not. Will it s= way enough for us to achieve rough consensus? Maybe. IMHO - worth finding o= ut. On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD > wrote: +1 to not having MTI codec discussion unless some progress has been made on= VP8 at MPEG. Any news on that? I'm sharing harald's feeling that there wa= s no change on the members position. On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: On 10/17/2014 12:02 AM, Bernard Aboba wrote: One thing we could do instead of wasting time on MTI is to actually make pr= ogress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could actual= ly interoperate regardless of the codec. The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure. I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I would pref= er that ecosystem to be one where it's possible to field the box without ma= king prior arrangements with anyone about licenses. This argument hasn't changed one whit since last time we discussed it. And = I don't see much movement on the specifics of the proposals either. We'll have to interoperate well with the codecs we field. So using some tim= e to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't fi= nished either. There's one sentence that needs to be removed.) I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer= to re-discuss based on the knowledge that some significant players have ac= tually changed their minds. At the moment, I don't see signs that any of the poll respondents have said= "I have changed my mind". Harald On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: On 16 October 2014 14:17, Matthew Kaufman > wrote: And that's because something substantive has changed, or simply because wasting the WG time on this again is more entertaining than actually finishing a specification that can be independently implemented by all browser vendors? (A specification that we are nowhere near having, as far a= s I can tell) Personally, I've found the reprieve from this fight refreshing. And it would appear that we've made some real progress as a result. I'd suggest that if we don't have new information, we continue to spend our time productively. If we can't find topics to occupy our meeting agenda time, then maybe we can free an agenda slot. _______________________________________________ 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 -- Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard * _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net _______________________________________________ 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 -- Surveillance is pervasive. Go Dark. _______________________________________________ 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_949EF20990823C4C85C18D59AA11AD8B263123FR712WXCHMBA11zeu_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
With respect to audio codecs I wa= s replying to a question from the previous message in the thread. But...
 
The MTI discussion does not close= the door on any codec, as any codec can be supported, just not mandatory t= o implement.
 
Your argument to eliminate H.264 = only applies if you can either eliminate interworking with the rest of the = world or you can persuade all those legacy devices to remove H.264 and use something else, which in my view is totally imprac= tical.
 
MTI might persuade usage of that = codec, but it will only do that if the MTI codec actually supports end to e= nd communication of the required video capabilities. Neither VP8 or H.264 fit all those requirements.
 
Keith

From: Justin Uberti [mailto:juberti= @google.com]
Sent: 20 October 2014 23:29
To: DRAGE, Keith (Keith)
Cc: Andrew Allen; chris.cavigioli@intel.com; harald@alvestrand.no; b= ernard.aboba@gmail.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Plan for MTI video codec?

From the subject "Plan for MTI video codec", I t= hought this discussion was about video codecs, not AMR interop. 

An astute observer might take note of the fact that our inability to c= lose the door on H.264 is providing an opportunity to other royalty-bearing= codecs that want to join the party.

On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (K= eith) <kei= th.drage@alcatel-lucent.com> wrote:
The scenario where you might want to transcode the audio codec is where y= ou have wideband audio in both the OPUS and the AMR, and you believe by tra= nscoding you can achieve a wideband quality, rather than falling back to G.711. And for interworking between 3GPP devic= es that are not using webRTC, the audio will still be AMR or AMR-WB or EVC,= not OPUS.
 
But audio transcoding is not particularly a concern for me. It is trying = where possible to avoid video transcoding.
 
Keith

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen
Sent: 20 October 2014 14:52
To: c= hris.cavigioli@intel.com; harald@alvestrand= .no; bernard.aboba@gmail.com

Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?


Chris

What is the scenario that dictates the need for direct transcoding between = OPUS and AMR?

All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE devi= ces OPUS can be negotiated with non mobile RTCweb devices end to end.

My expectation is that for mobile devices the RTCweb client will also have = access to the embedded AMR codec so mobile RTCweb devices can interoperate = using AMR with non-RTCweb enabled mobile IMS devices that support AMR.

For interoperation between non mobile RTCweb devices and mobile non RTCweb = IMS devices the non mobile RTCweb device can use G.711 to the transcoder fo= r transcoding to AMR on the other side. While not ideal this will be no wor= se than non mobile RTCweb devices interoperating with circuit switched only mobile devices which will be for= ced to interoperate via the PSTN.

As RTCweb becomes universal on mobile devices I expect that support for OPU= S will become native and mobile IMS devices will also be able to use OPUS e= ven when operating without the use of the browser (i.e. in non RTCweb mode)= for better interoperation with non-mobile RTCweb devices.

The lifetime of most mobile devices is 2 years or less so this is likely to= be mainly a short term transition issue only.

Andrew
 
From= : Cavigioli, Chris [mailto:chris.cavigioli@intel.com]
Sent: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
To: Harald Alvestrand <harald@alvestrand.no>; Bernard Aboba <bernard.aboba@gmail.com>
Cc: rtcweb@ietf= .org <rtcweb@ie= tf.org>
Subject: Re: [rtcweb] Plan for MTI video codec?
 

Harald said: 

“We made the mistake of having an MTI discussi= on previously with not enough details on that subject…”=

 

We didn’t have quantitative data earli= er for a data-driven decision.  Future Web – LTE interop is impo= rtant.  A group of us in GSMA have been looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messagin= g), specifically looking at user experience impact of latency introduced by= added in-network transcoding.  GSMA has approved the whitepaper and i= t is being prepared for public distribution. 

 

WebRTC – LTE transcoding is now MANDAT= ORY because of “WebRTC Audio Codec and Processing Requirements”= . http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where M= TI audio codecs in WebRTC and in LTE are dissimilar.  Thus, REGARDLESS= of the video codecs, there is already a significant degradation imposed on Web – LTE links if only MTI codec= s are used.  The only systems to avoid this are those which implement = OPTIONAL audio codecs to be transcoder-free with LTE.  The same can ap= ply for video codecs.

 

The GSMA whitepaper refers to:=

1. = ;    Quantitative voice-over-LTE (VoLTE) del= ay limits were agreed-to by 3GPP SA4 in August 2014.  To paraphrase, p= erformance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec ope= ration, the sum of the UE delays in sending and receiving directions (TS + TR) should be =98 150ms. If this performance obje= ctive cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR) shall in any case be =98 190ms.

2. = ;    OPUS – AMR transcoding adds an ad= ditional 211.5 ms implementation-agnostic (TS + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3. = ;    To put these numbers in perspective, it= is in general desirable to minimize UE delays to ensure low enough end-to-= end delays and hence a good conversational experience.  Increasing delay causes people to double-talk making con= versations increasingly frustrating.  Guidance to stay below 400 ms ma= ximum one-way delay is found in ITU-T Recommendation G.114 and the computat= ional E-model is in ITU-T Recommendation G.107.

 

This is a complex topic with many network fa= ctors in play.  LTE operators in 3GPP seek UE delays (TS &#= 43; TR) around 150 ms.  Adding OPUS – AMR transcoding in the network imposes an additional 211.5 ms on t= op of that, just for audio.  Optionally using AMR in WebRTC, those 211= .5 ms can be eliminated, delivering a superior end-user experience. 

 

CONCLUSION:  regardless of MTI codec ch= oices in WebRTC, to provide a good WebRTC – LTE interop experience, e= merging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely= AMR/AMR-WB and H.264.

 

POSITION:  To be clear, several Intel S= oCs launched at MWC this year for smartphones and tablets support both VP8 = and H.264 hardware encode and decode – so Intel is codec-neutral in this MTI debate.  Additionally, Intel has h= igh-performance solutions for transcoding.  However, we wish to inform= the industry, with quantitative data, about impact to end-user experience = of mandating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impa= ct of already having mandated transcoding on the audio side.<= /span>

 

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Mul= timedia, Mobile and Communications Group (MCG)

+1 (415) 254-4545 mob= ile

+1 (408) 653-8348 des= k

+1 (408) 884-2400 fax=

This e-mail may contain confidential and pri= vileged material for the sole use of the intended recipient(s).  Any r= eview or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the send= er and delete all copies.

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?=

 

Harald said: 

 

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad....."

 

[BA]  I agree that the lack of interoperability= is largely "codec independent":   that is, implementations = based on different mechanisms for congestion control, repair, etc. will exh= ibit interoperability problems, regardless of the codec chosen.   The real test for RTCWEB will be to move beyond "inter= operability of implementations sharing source code"  to "int= eroperability of independent implementations, based on open standards"= .   

 

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:<= u>

"And its one of the issues holding up wider ado= ption of the technology"

 

[BA] Specifying an MTI encoder/decoder is not suffic= ient for interoperability.  It is also necessary to specify the transp= ort in enough detail to allow independent implementations that interoperate= well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienc= ed. 


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....




 

We made the mistake of having an MTI discussion prev= iously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.=  

 

So if we are to have the discussion again, it should= occur in the context of detailed specifications and interoperability repor= ts.

 

 

 

 

 

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrose= n.net> wrote:

I'm in favor of taking another run at this. <= u>

 

The working group has repeatedly said that an MTI co= dec is something we need to produce. And its one of the issues holding up w= ider adoption of the technology (not the only one for sure).<= /p>

 

And things have changed since the last meeting, a ye= ar ago now (November in Vancouver). Cisco's open264 plugin shipped and now = just recently is integrated into Firefox. iOS8 shipped with APIs for H264. = There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough fo= r us to achieve rough consensus? Maybe. IMHO - worth finding out.=

 

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLAR= D <agouaillar= d@gmail.com> wrote:

+1 to not having MTI codec discussion unless som= e progress has been made on VP8 at MPEG. Any news on that? I'm sharing= harald's  feeling that there was no change on the members position.&n= bsp;

 

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:<= u>

One thing we could do instead of wasting time on MTI= is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-vi= deo, so we could actually interoperate regardless of the codec.


The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the box = without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. And = I don't see much movement on the specifics of the proposals either.

We'll have to interoperate well with the codecs we field. So using some tim= e to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn't fi= nished either. There's one sentence that needs to be removed.)

I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd prefer= to re-discuss based on the knowledge that some significant players have ac= tually changed their minds.

At the moment, I don't see signs that any of the poll respondents have said= "I have changed my mind".

Harald





On Oct 16, 2014, at 2:= 28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at>= ; wrote:
And that's because something substantive has changed, or simply because
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)

Personally, I've found the reprieve from this fight = refreshing.  And
it would appear that we've made some real progress as a result.  I'd suggest that if we don't have new information, we continue to spend
our time productively.  If we can't find topics to occupy our meeting<= br> agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



 

--

Alex. Gouaillard, PhD= , PhD, MBA

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

CTO - Temasys Communi= cations, S'pore / Mountain View

President - CoSMo Sof= tware, Cambridge, MA

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

=9E   &nb= sp;      


_______________________________________________
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

  

-- 
Surveillance is pervasive. Go Dark.<=
/u>


_______________________________________________
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_949EF20990823C4C85C18D59AA11AD8B263123FR712WXCHMBA11zeu_-- From nobody Tue Oct 21 07:32:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6C01A6F7F for ; Tue, 21 Oct 2014 07:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5x6LvS8p4TK for ; Tue, 21 Oct 2014 07:32:25 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3D86B1A6F45 for ; Tue, 21 Oct 2014 07:32:25 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 7461623F049B; Tue, 21 Oct 2014 16:32:24 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 16:32:24 +0200 From: "Hutton, Andrew" To: Emil Ivov , "Cullen Jenning (work)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Agenda for the upcoming meeting Thread-Index: AQHP6WQkBv1/hIPnb0eX/BgOoxserpw4SxAAgAFk34D//5eAAIABWkiA Date: Tue, 21 Oct 2014 14:32:23 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5CE58C@MCHP04MSX.global-ad.net> References: <54442F52.3090608@andyet.net> <3A26E75E-BEF0-4D71-9372-01CE9D199E3D@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.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/E-eMyum1nk-_gSyZE0O1DXLQj1Y Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 14:32:26 -0000 On: 20 October 2014 20:42 Emil Ivov Wrote: > On 20 Oct 2014 8:55 PM, "Cullen Jennings (fluffy)" > wrote: > > > > > > So lets be clear here. >=20 > Good idea! >=20 > > Every time we checked, there has been consensus that we need an MTI > codec. > > So right now this work is sort of blocked on that >=20 > So clearly, what work is blocked on that exactly? >=20 The only thing that seems to be blocked is the MTI Codec decision and here = I think we need to accept that no decision is better than a wrong decision = or a decision that divides the community.=20 Therefore I suggest we continue to ignore the issue and move on. Andy From nobody Tue Oct 21 07:45:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0721A700B for ; Tue, 21 Oct 2014 07:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViMZrUnJ6pyW for ; Tue, 21 Oct 2014 07:45:34 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5DD1A86ED for ; Tue, 21 Oct 2014 07:45:33 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so758316ier.2 for ; Tue, 21 Oct 2014 07:45:33 -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=XeS7cNB8YRDMnjLRDpnHGZtC4KxKGf2lU0H4SWDF0Xk=; b=HgrkXXW6fNWx7iK4et/NBCkj7BkvcBVI4N/oeRbKX23k2K9ijXiXn/r1bUU+6L0NWz 6RG5gL31WdDH0pr1NpGOWLQzEvirt4UEsRGoMuyR3dsa0U5kSOEM7yepOo1UDWSRTLc+ hV6rKgzUYN+/hXXp6Fla/qgpgVcz1iOzcCZU2x2qDU3iA5coPx3jRH8YneTzZS86/A7C pyUsN+2Yng+Om1iNmz94DBYtddEKln6bWXhvVy+lJ8fQzN4uTceejlDmbfWT0O5w7++w Nh30Y+OelxLfWV6RnzYOqQfgHtv7Q10fnUvsKjXGFYPggAHpapOqQLfyfZIE9v1EBlT0 G9pQ== MIME-Version: 1.0 X-Received: by 10.107.31.202 with SMTP id f193mr37956246iof.16.1413902733176; Tue, 21 Oct 2014 07:45:33 -0700 (PDT) Received: by 10.43.3.4 with HTTP; Tue, 21 Oct 2014 07:45:32 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B263123@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B2627F1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B263123@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 21 Oct 2014 07:45:32 -0700 Message-ID: From: Ted Hardie To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=001a1140cac02877a00505efe220 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uhQAsMwDBs0ferbZ-J8yHIYwl1k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 14:45:40 -0000 --001a1140cac02877a00505efe220 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would appreciate folks moving off the question of whether the video codec discussion should be part of the agenda could change the topic. thanks, Ted On Tue, Oct 21, 2014 at 2:08 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > With respect to audio codecs I was replying to a question from the > previous message in the thread. But... > > The MTI discussion does not close the door on any codec, as any codec can > be supported, just not mandatory to implement. > > Your argument to eliminate H.264 only applies if you can either eliminate > interworking with the rest of the world or you can persuade all those > legacy devices to remove H.264 and use something else, which in my view i= s > totally impractical. > > MTI might persuade usage of that codec, but it will only do that if the > MTI codec actually supports end to end communication of the required vide= o > capabilities. Neither VP8 or H.264 fit all those requirements. > > Keith > > ------------------------------ > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* 20 October 2014 23:29 > *To:* DRAGE, Keith (Keith) > *Cc:* Andrew Allen; chris.cavigioli@intel.com; harald@alvestrand.no; > bernard.aboba@gmail.com; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > From the subject "Plan for MTI video codec", I thought this discussion > was about video codecs, not AMR interop. > > An astute observer might take note of the fact that our inability to > close the door on H.264 is providing an opportunity to other > royalty-bearing codecs that want to join the party. > > On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > >> The scenario where you might want to transcode the audio codec is where >> you have wideband audio in both the OPUS and the AMR, and you believe by >> transcoding you can achieve a wideband quality, rather than falling back= to >> G.711. And for interworking between 3GPP devices that are not using webR= TC, >> the audio will still be AMR or AMR-WB or EVC, not OPUS. >> >> But audio transcoding is not particularly a concern for me. It is trying >> where possible to avoid video transcoding. >> >> Keith >> >> ------------------------------ >> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Andrew >> Allen >> *Sent:* 20 October 2014 14:52 >> *To:* chris.cavigioli@intel.com; harald@alvestrand.no; >> bernard.aboba@gmail.com >> >> *Cc:* rtcweb@ietf.org >> *Subject:* Re: [rtcweb] Plan for MTI video codec? >> >> >> Chris >> >> What is the scenario that dictates the need for direct transcoding >> between OPUS and AMR? >> >> All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE >> devices OPUS can be negotiated with non mobile RTCweb devices end to end= . >> >> My expectation is that for mobile devices the RTCweb client will also >> have access to the embedded AMR codec so mobile RTCweb devices can >> interoperate using AMR with non-RTCweb enabled mobile IMS devices that >> support AMR. >> >> For interoperation between non mobile RTCweb devices and mobile non >> RTCweb IMS devices the non mobile RTCweb device can use G.711 to the >> transcoder for transcoding to AMR on the other side. While not ideal thi= s >> will be no worse than non mobile RTCweb devices interoperating with circ= uit >> switched only mobile devices which will be forced to interoperate via th= e >> PSTN. >> >> As RTCweb becomes universal on mobile devices I expect that support for >> OPUS will become native and mobile IMS devices will also be able to use >> OPUS even when operating without the use of the browser (i.e. in non RTC= web >> mode) for better interoperation with non-mobile RTCweb devices. >> >> The lifetime of most mobile devices is 2 years or less so this is likely >> to be mainly a short term transition issue only. >> >> Andrew >> >> *From*: Cavigioli, Chris [mailto:chris.cavigioli@intel.com] >> *Sent*: Sunday, October 19, 2014 09:20 PM Eastern Standard Time >> *To*: Harald Alvestrand ; Bernard Aboba < >> bernard.aboba@gmail.com> >> *Cc*: rtcweb@ietf.org >> *Subject*: Re: [rtcweb] Plan for MTI video codec? >> >> >> Harald said: >> >> =E2=80=9CWe made the mistake of having an MTI discussion previously with= not >> enough details on that subject=E2=80=A6=E2=80=9D >> >> >> >> We didn=E2=80=99t have quantitative data earlier for a data-driven decis= ion. >> Future Web =E2=80=93 LTE interop is important. A group of us in GSMA ha= ve been >> looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based >> voice/video/messaging), specifically looking at user experience impact o= f >> latency introduced by added in-network transcoding. GSMA has approved t= he >> whitepaper and it is being prepared for public distribution. >> >> >> >> WebRTC =E2=80=93 LTE transcoding is now MANDATORY because of =E2=80=9CWe= bRTC Audio Codec >> and Processing Requirements=E2=80=9D. >> http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio >> codecs in WebRTC and in LTE are dissimilar. Thus, REGARDLESS of the vid= eo >> codecs, there is already a significant degradation imposed on Web =E2=80= =93 LTE >> links if only MTI codecs are used. The only systems to avoid this are >> those which implement OPTIONAL audio codecs to be transcoder-free with >> LTE. The same can apply for video codecs. >> >> >> >> The GSMA whitepaper refers to: >> >> 1. Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to >> by 3GPP SA4 in August 2014. To paraphrase, performance objectives for >> maximum VoLTE device delays in error and jitter free conditions and AMR >> speech codec operation, the sum of the UE delays in sending and receivin= g >> directions (TS + TR) should be =E2=89=A4 150ms. If this performance obje= ctive >> cannot be met, the sum of the UE delays in sending and receiving directi= ons >> (TS + TR) shall in any case be =E2=89=A4 190ms. >> >> 2. OPUS =E2=80=93 AMR transcoding adds an additional 211.5 ms >> implementation-agnostic (TS + TR) delay, including 40 ms for jitter >> buffer and 40 ms for discontinuous reception (DRX). >> >> 3. To put these numbers in perspective, it is in general desirable >> to minimize UE delays to ensure low enough end-to-end delays and hence a >> good conversational experience. Increasing delay causes people to >> double-talk making conversations increasingly frustrating. Guidance to >> stay below 400 ms maximum one-way delay is found in ITU-T Recommendation >> G.114 and the computational E-model is in ITU-T Recommendation G.107. >> >> >> >> This is a complex topic with many network factors in play. LTE operator= s >> in 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS =E2=80=93 A= MR >> transcoding in the network imposes an additional 211.5 ms on top of that= , >> just for audio. Optionally using AMR in WebRTC, those 211.5 ms can be >> eliminated, delivering a superior end-user experience. >> >> >> >> CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a goo= d >> WebRTC =E2=80=93 LTE interop experience, emerging WebRTC systems must ac= commodate >> MTI codecs already deployed in the LTE domain and in mobile operating >> systems, namely AMR/AMR-WB and H.264. >> >> >> >> POSITION: To be clear, several Intel SoCs launched at MWC this year for >> smartphones and tablets support both VP8 and H.264 hardware encode and >> decode =E2=80=93 so Intel is codec-neutral in this MTI debate. Addition= ally, Intel >> has high-performance solutions for transcoding. However, we wish to inf= orm >> the industry, with quantitative data, about impact to end-user experienc= e >> of mandating such transcoding so IETF can make a data-driven decision on >> video codecs as well as reflect on the impact of already having mandated >> transcoding on the audio side. >> >> >> >> Chris Cavigioli >> >> Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile >> and Communications Group (MCG) >> >> +1 (415) 254-4545 mobile >> >> +1 (408) 653-8348 desk >> >> +1 (408) 884-2400 fax >> >> This e-mail may contain confidential and privileged material for the sol= e >> use of the intended recipient(s). Any review or distribution by others = is >> strictly prohibited. If you are not the intended recipient, please conta= ct >> the sender and delete all copies. >> >> >> >> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Bernard >> Aboba >> *Sent:* Sunday, October 19, 2014 2:29 PM >> *To:* Harald Alvestrand >> *Cc:* rtcweb@ietf.org >> *Subject:* Re: [rtcweb] Plan for MTI video codec? >> >> >> >> Harald said: >> >> >> >> "Bernard, >> >> >> I think this is, to a large degree, codec independent. >> >> We have demonstrated interoperability on VP8 between Firefox and Chrome, >> and usage of various mechanisms for congestion control and repair of pac= ket >> loss being applied in live services. >> >> So it can't be all bad....." >> >> >> >> [BA] I agree that the lack of interoperability is largely "codec >> independent": that is, implementations based on different mechanisms f= or >> congestion control, repair, etc. will exhibit interoperability problems, >> regardless of the codec chosen. The real test for RTCWEB will be to mo= ve >> beyond "interoperability of implementations sharing source code" to >> "interoperability of independent implementations, based on open standard= s". >> >> >> >> >> On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand >> wrote: >> >> On 10/19/2014 05:43 PM, Bernard Aboba wrote: >> >> "And its one of the issues holding up wider adoption of the technology" >> >> >> >> [BA] Specifying an MTI encoder/decoder is not sufficient for >> interoperability. It is also necessary to specify the transport in enou= gh >> detail to allow independent implementations that interoperate well enoug= h >> to be usable in a wide variety of scenarios, including wireless networks >> where loss is commonly experienced. >> >> >> Bernard, >> >> I think this is, to a large degree, codec independent. >> >> We have demonstrated interoperability on VP8 between Firefox and Chrome, >> and usage of various mechanisms for congestion control and repair of pac= ket >> loss being applied in live services. >> >> So it can't be all bad..... >> >> >> >> >> >> >> We made the mistake of having an MTI discussion previously with not >> enough details on that subject, particularly with respect to H.264. >> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. >> >> >> >> So if we are to have the discussion again, it should occur in the contex= t >> of detailed specifications and interoperability reports. >> >> >> >> >> >> >> >> >> >> >> >> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg >> wrote: >> >> I'm in favor of taking another run at this. >> >> >> >> The working group has repeatedly said that an MTI codec is something we >> need to produce. And its one of the issues holding up wider adoption of = the >> technology (not the only one for sure). >> >> >> >> And things have changed since the last meeting, a year ago now (November >> in Vancouver). Cisco's open264 plugin shipped and now just recently is >> integrated into Firefox. iOS8 shipped with APIs for H264. There are othe= r >> things worth noting. Will this change the minds of everyone? Surely not. >> Will it sway enough for us to achieve rough consensus? Maybe. IMHO - wor= th >> finding out. >> >> >> >> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < >> agouaillard@gmail.com> wrote: >> >> +1 to not having MTI codec discussion unless some progress has been made >> on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that the= re >> was no change on the members position. >> >> >> >> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand >> wrote: >> >> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >> >> One thing we could do instead of wasting time on MTI is to actually make >> progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could >> actually interoperate regardless of the codec. >> >> >> The big argument for an MTI is actually the one stated in -overview: It >> guards against interoperability failure. >> >> I would like to have an ecosystem where one can field a box, connect it >> to everything else, and run well for *some* level of "well" - and I woul= d >> prefer that ecosystem to be one where it's possible to field the box >> without making prior arrangements with anyone about licenses. >> >> This argument hasn't changed one whit since last time we discussed it. >> And I don't see much movement on the specifics of the proposals either. >> >> We'll have to interoperate well with the codecs we field. So using some >> time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 is= n't >> finished either. There's one sentence that needs to be removed.) >> >> I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd >> prefer to re-discuss based on the knowledge that some significant player= s >> have actually changed their minds. >> >> At the moment, I don't see signs that any of the poll respondents have >> said "I have changed my mind". >> >> Harald >> >> >> >> >> >> On Oct 16, 2014, at 2:28 PM, Martin Thomson >> wrote: >> >> On 16 October 2014 14:17, Matthew Kaufman wrote: >> And that's because something substantive has changed, or simply because >> wasting the WG time on this again is more entertaining than actually >> finishing a specification that can be independently implemented by all >> browser vendors? (A specification that we are nowhere near having, as fa= r >> as >> I can tell) >> >> Personally, I've found the reprieve from this fight refreshing. And >> it would appear that we've made some real progress as a result. I'd >> suggest that if we don't have new information, we continue to spend >> our time productively. If we can't find topics to occupy our meeting >> agenda time, then maybe we can free an agenda slot. >> >> _______________________________________________ >> 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 >> >> >> >> >> >> -- >> >> Alex. Gouaillard, PhD, PhD, MBA >> >> >> ------------------------------------------------------------------------= ------------ >> >> CTO - Temasys Communications, S'pore / Mountain View >> >> President - CoSMo Software, Cambridge, MA >> >> >> ------------------------------------------------------------------------= ------------ >> >> sg.linkedin.com/agouaillard >> >> =C2=B7 >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> >> -- >> >> Jonathan Rosenberg, Ph.D. >> jdrosen@jdrosen.net >> http://www.jdrosen.net >> >> >> _______________________________________________ >> 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 >> >> >> >> -- >> >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> 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 > > --001a1140cac02877a00505efe220 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would appreciate folks moving off the question= of whether the video codec discussion should be part of the agenda could c= hange the topic.

thanks,

Ted

On Tue, Oct 21, 2014 at 2:08 AM, D= RAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
With respect to audio codecs I was replying to a question from the previo= us message in the thread. But...
=C2=A0
The MTI discussion does not close the door on any codec, as any codec can= be supported, just not mandatory to implement.
=C2=A0
Your argument to eliminate H.264 only applies if you can either eliminate= interworking with the rest of the world or you can persuade all those lega= cy devices to remove H.264 and use something else, which in my view is totally imprac= tical.
=C2=A0
MTI might persuade usage of that codec, but it will only do that if the M= TI codec actually supports end to end communication of the required video c= apabilities. Neither VP8 or H.264 fit all those requirements.
=C2=A0
Keith

From: Justin Uberti [mailto:<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com]
Sent: 20 October 2014 23:29
To: DRAGE, Keith (Keith)
Cc: Andrew Allen; chris.cavigioli@intel.com; harald@alvestrand.no; bernard.aboba@gmail.com; rtcweb@ietf.org

Subject: Re: [rtcweb] Plan for MTI video codec?

From the subject "Plan for MTI video codec", I t= hought this discussion was about video codecs, not AMR interop.=C2=A0

An astute observer might take note of the fact that our inability to c= lose the door on H.264 is providing an opportunity to other royalty-bearing= codecs that want to join the party.

On Mon, Oct 20, 2014 at 7:34 AM, DRAGE, Keith (K= eith) <kei= th.drage@alcatel-lucent.com> wrote:
The scenario where you might want to transcode the audio codec is where y= ou have wideband audio in both the OPUS and the AMR, and you believe by tra= nscoding you can achieve a wideband quality, rather than falling back to G.711. And for interworking between 3GPP devic= es that are not using webRTC, the audio will still be AMR or AMR-WB or EVC,= not OPUS.
=C2=A0
But audio transcoding is not particularly a concern for me. It is trying = where possible to avoid video transcoding.
=C2=A0
Keith

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen
Sent: 20 October 2014 14:52
To: c= hris.cavigioli@intel.com; harald@alvestrand= .no; bernard.aboba@gmail.com

Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?


Chris

What is the scenario that dictates the need for direct transcoding between = OPUS and AMR?

All RTCweb clients MUST support OPUS so for Web browsers on mobile LTE devi= ces OPUS can be negotiated with non mobile RTCweb devices end to end.

My expectation is that for mobile devices the RTCweb client will also have = access to the embedded AMR codec so mobile RTCweb devices can interoperate = using AMR with non-RTCweb enabled mobile IMS devices that support AMR.

For interoperation between non mobile RTCweb devices and mobile non RTCweb = IMS devices the non mobile RTCweb device can use G.711 to the transcoder fo= r transcoding to AMR on the other side. While not ideal this will be no wor= se than non mobile RTCweb devices interoperating with circuit switched only mobile devices which will be for= ced to interoperate via the PSTN.

As RTCweb becomes universal on mobile devices I expect that support for OPU= S will become native and mobile IMS devices will also be able to use OPUS e= ven when operating without the use of the browser (i.e. in non RTCweb mode)= for better interoperation with non-mobile RTCweb devices.

The lifetime of most mobile devices is 2 years or less so this is likely to= be mainly a short term transition issue only.

Andrew
=C2=A0
From: Cavigioli, Chris [mailto:chris.cavigioli@intel.com]
Sent: Sunday, October 19, 2014 09:20 PM Eastern Standard Time
To: Harald Alvestrand <harald@alvestrand.no>; Bernard Aboba <bernard.aboba@gmail.com>
Cc: rtcweb@ietf= .org <rtcweb@ie= tf.org>
Subject: Re: [rtcweb] Plan for MTI video codec?
=C2=A0

Harald said:=C2=A0

=E2=80=9CWe made the mistake of having an MTI discus= sion previously with not enough details on that subject=E2=80=A6=E2=80=9D

=C2=A0

We didn=E2=80=99t have quantitati= ve data earlier for a data-driven decision.=C2=A0 Future Web =E2=80=93 LTE = interop is important.=C2=A0 A group of us in GSMA have been looking at WebR= TC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messagin= g), specifically looking at user experience impact of latency introduced by= added in-network transcoding.=C2=A0 GSMA has approved the whitepaper and i= t is being prepared for public distribution.=C2=A0

=C2=A0

WebRTC =E2=80=93 LTE transcoding = is now MANDATORY because of =E2=80=9CWebRTC Audio Codec and Processing Requ= irements=E2=80=9D. http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where M= TI audio codecs in WebRTC and in LTE are dissimilar.=C2=A0 Thus, REGARDLESS= of the video codecs, there is already a significant degradation imposed on Web =E2=80=93 LTE links if only MTI cod= ecs are used.=C2=A0 The only systems to avoid this are those which implemen= t OPTIONAL audio codecs to be transcoder-free with LTE.=C2=A0 The same can = apply for video codecs.

=C2=A0

The GSMA whitepaper refers to:=

1.=C2=A0=C2=A0=C2=A0=C2=A0 Quantitative voice-over-LTE = (VoLTE) delay limits were agreed-to by 3GPP SA4 in August 2014.=C2=A0 To pa= raphrase, performance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec ope= ration, the sum of the UE delays in sending and receiving directions (TS + TR) should be =E2=89=A4 150ms. If this performance ob= jective cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR)= shall in any case be =E2=89=A4 190ms.

2.=C2=A0=C2=A0=C2=A0=C2=A0 OPUS =E2=80=93 AMR transcodi= ng adds an additional 211.5 ms implementation-agnostic (TS + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.=C2=A0=C2=A0=C2=A0=C2=A0 To put these numbers in pers= pective, it is in general desirable to minimize UE delays to ensure low eno= ugh end-to-end delays and hence a good conversational experience.=C2=A0 Increasing delay causes people to double-talk making con= versations increasingly frustrating.=C2=A0 Guidance to stay below 400 ms ma= ximum one-way delay is found in ITU-T Recommendation G.114 and the computat= ional E-model is in ITU-T Recommendation G.107.

=C2=A0

This is a complex topic with many= network factors in play.=C2=A0 LTE operators in 3GPP seek UE delays (TS + TR) around 150 ms.=C2=A0 Adding OPUS =E2=80=93 AMR transcoding in the network imposes an additional 211.5 ms on= top of that, just for audio.=C2=A0 Optionally using AMR in WebRTC, those 2= 11.5 ms can be eliminated, delivering a superior end-user experience.=C2=A0

=C2=A0

CONCLUSION: =C2=A0regardless of M= TI codec choices in WebRTC, to provide a good WebRTC =E2=80=93 LTE interop = experience, emerging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely= AMR/AMR-WB and H.264.

=C2=A0

POSITION:=C2=A0 To be clear, seve= ral Intel SoCs launched at MWC this year for smartphones and tablets suppor= t both VP8 and H.264 hardware encode and decode =E2=80=93 so Intel is codec-neutral in this MTI debate.=C2=A0 Additionally, Intel has h= igh-performance solutions for transcoding.=C2=A0 However, we wish to inform= the industry, with quantitative data, about impact to end-user experience = of mandating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impa= ct of already having mandated transcoding on the audio side.<= /span>

=C2=A0

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group (MCG)

+1 (415) 254-4545 = mobile

+1 (408) 653-8348 = desk

+1 (408) 884-2400 = fax

This e-mail may contain confident= ial and privileged material for the sole use of the intended recipient(s).= =C2=A0 Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the send= er and delete all copies.

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf= .org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?=

=C2=A0

Harald said:=C2=A0

=C2=A0

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad....."=

=C2=A0

[BA] =C2=A0I agree that the lack of interoperability= is largely "codec independent": =C2=A0 that is, implementations = based on different mechanisms for congestion control, repair, etc. will exh= ibit interoperability problems, regardless of the codec chosen. =C2=A0 The real test for RTCWEB will be to move beyond "inter= operability of implementations sharing source code" =C2=A0to "int= eroperability of independent implementations, based on open standards"= . =C2=A0=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:<= u>

"And its one of the issues holding up wider ado= ption of the technology"

=C2=A0

[BA] Specifying an MTI encoder/decoder is not suffic= ient for interoperability.=C2=A0 It is also necessary to specify the transp= ort in enough detail to allow independent implementations that interoperate= well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienc= ed.=C2=A0


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....




=C2=A0

We made the mistake of having an MTI discussion prev= iously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.= =C2=A0

=C2=A0

So if we are to have the discussion again, it should= occur in the context of detailed specifications and interoperability repor= ts.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrose= n.net> wrote:

I'm in favor of taking another run at this. <= /u>

=C2=A0

The working group has repeatedly said that an MTI co= dec is something we need to produce. And its one of the issues holding up w= ider adoption of the technology (not the only one for sure).<= /p>

=C2=A0

And things have changed since the last meeting, a ye= ar ago now (November in Vancouver). Cisco's open264 plugin shipped and = now just recently is integrated into Firefox. iOS8 shipped with APIs for H2= 64. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough fo= r us to achieve rough consensus? Maybe. IMHO - worth finding out.=

=C2=A0

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLAR= D <agouaillar= d@gmail.com> wrote:

+1 to not having MTI codec discussion unless some pr= ogress has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing= harald's =C2=A0feeling that there was no change on the members positio= n.=C2=A0

=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:<= u>

One thing we could do instead of wasting time on MTI= is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-vi= deo, so we could actually interoperate regardless of the codec.


The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald





On Oct 16, 2014, at 2:2= 8 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at>= ; wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)

Personally, I've found the reprieve from this fi= ght refreshing.=C2=A0 And
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



=C2=A0

--

Alex. Gouaillard, PhD,= PhD, MBA

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

CTO - Temasys Communic= ations, S'pore / Mountain View

President - CoSMo Soft= ware, Cambridge, MA

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

=C2=B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0


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



=C2=A0

--


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

=C2=A0

=C2=A0 

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

=C2=A0 

-- 
Surveillance is pervasive. Go Dark.


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

=C2=A0


_______________________________________________
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


--001a1140cac02877a00505efe220-- From nobody Tue Oct 21 09:26:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DAD1A895E for ; Tue, 21 Oct 2014 09:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.821 X-Spam-Level: X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OUsz4bAjGSV for ; Tue, 21 Oct 2014 09:26:00 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D481A8904 for ; Tue, 21 Oct 2014 09:26:00 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so1240423qcw.31 for ; Tue, 21 Oct 2014 09:25:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=xV4ji0q/Hjj5UAWHBhjrwQ0Y8z/wRlVU5kP1jwblpdw=; b=TZB3rt2exYJf2YHVwIpwxMLUnV7XTzoGcU6WziWFqYmG+KROsRPtaQGz97YdEyzHAN LOVQ5q0Zifufrgu5mBU2XZtnIzYoQdnyIqM2ig/JW+TTJGMXsNxuTrIaDGszYvkonQq/ KVClsNcXs5z36tre2b9d+FydB5H3hXdHTn7m3AFWc8zb8UtwlybrT/ajK/R7ABGHv5lA wMOj8US4H5Gpw+uRc12DcmA/obQ1tVlI/72FU06H8gcIz8CIGDzU6nVw1IpORHPmwQ1U 6sURAKYDmEYWhJDd3LvRfJp4mWxsyIVPcmVlG/5yjezG833xG3/r85w4OrRquz8KFeCx YVYQ== X-Gm-Message-State: ALoCoQkLyjOdz+vZi5Y5PeHcveuA6WWHccK4EpHXhXMswI2O8feZIf6EGRmHO2aJfzEp/Xow+Tef X-Received: by 10.140.21.199 with SMTP id 65mr3574874qgl.86.1413908759110; Tue, 21 Oct 2014 09:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Tue, 21 Oct 2014 09:25:38 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 Oct 2014 18:25:38 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BrSqExA71QF2IdgqD2FlWBy3rbY Subject: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 16:26:02 -0000 Hi, May I know which SSRC (345259865 or 2693756249) will be used for the real media stream (plus RED and FEC) and which SSRC will be used for RTX? -------------------------- m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 a=3Dmid:video a=3Drtpmap:100 VP8/90000 a=3Drtpmap:116 red/90000 a=3Drtpmap:117 ulpfec/90000 a=3Drtpmap:96 rtx/90000 a=3Dfmtp:96 apt=3D100 a=3Dssrc-group:FID 345259865 2693756249 a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 c0134f05-e7c2-4afd-a979-4e224de5eb91 a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 c0134f05-e7c2-4afd-a979-4e224de5eb91 a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 ------------------------------- RFC 5576 does not clarify it at all: http://tools.ietf.org/html/rfc5576#section-4.2 -------------------------------------------------- 4.2. The "ssrc-group" Media Attribute a=3Dssrc-group: ... [..] The parameter is taken from the specification of the "group" attribute [RFC3388]. The initial semantic values defined for the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] and FEC (Forward Error Correction) [RFC4756]. In each case, the relationship among the grouped sources is the same as the relationship among corresponding sources in media streams grouped using the SDP "group" attribute. -------------------------------------------------- The referenced RFC 3388 neither clarifies it: --------------------------------------------------- 7.4 FID Semantics Several "m" lines grouped together using FID semantics form a media flow. A media agent handling a media flow that comprises several "m" lines MUST send a copy of the media to every "m" line part of the flow as long as the codecs and the direction attribute present in a particular "m" line allow it. It is assumed that the application uses only one codec at a time to encode the media produced. This codec MAY change dynamically during the session, but at any particular moment only one codec is in use. The application encodes the media using the current codec and checks one by one all the "m" lines that are part of the flow. If a particular "m" line contains the codec being used and the direction attribute is "sendonly" or "sendrecv", a copy of the encoded media is sent to the address/port specified in that particular media stream. If either the "m" line does not contain the codec being used or the direction attribute is neither "sendonly" nor "sendrecv", nothing is sent over this media stream. ---------------------------------------------------- So, how is the usage of ssrc-group? Where is it really defined? Can I put more than 2 ssrc together in the same ssrc-group line? How should the receiver interpret it? Does a ssrc-group always mean RTX usage? Where is that specified in the above SDP? Does not the above SDP look a complete mixture of hacks and workarounds? --=20 I=C3=B1aki Baz Castillo From nobody Tue Oct 21 10:31:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED4B1A1B4A for ; Tue, 21 Oct 2014 10:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJFyOxk-JNfI for ; Tue, 21 Oct 2014 10:31:44 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5B91A1AF0 for ; Tue, 21 Oct 2014 10:31:43 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hy4so824819vcb.0 for ; Tue, 21 Oct 2014 10:31:42 -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; bh=IzFt55UXPWrygA2iItbXqCG+vt3+5MMl70cM0gaZDcY=; b=XL6HXHIyKCOWN0H41gv+Y2vlMYZMSmPR35w08/znOePGd74TieNM/w05F3KH4h8NDh rT9lBThd68jroEACP5AXymMYjSGrtOAa0zw6/2jh632Jk64EXD9npj5tRVBIeXmUgk20 Zq4bWJVZm7VLd3pMsJk2piLoN2XByiL/MuFKT7B39WgSixJKQm7bWIPf0JTWQMh+1fnl ljlhjWz5VqfgM7g/i3C+eFCBP+yxjfW9YWjnh1N25krVqie/HxO9A/i/6J8c4XyszXIU v8NP86Q62JSGK+AJyZyQoZop+zGPsXQE/DXviY/3ksUKGX/WDiYA7GE/hodaWE5dBlrS cnYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IzFt55UXPWrygA2iItbXqCG+vt3+5MMl70cM0gaZDcY=; b=SSwj9opiScB71g0lJocXcE70GMTNHQf/vUsRT21Z13I9wCDDB2+t5yk7H3wjckDNFf mNzkMUeDv1QUGmksar5czwxEBWlTL8SS5Nwe2Z4+q1omUeGypb0Mi9gU1cEAfKLW9rpK Zua20qucWluiZzjs4qNWZGqmSyJXs5sOziy/giAxvrv3c8ydIs43rcl4OmrLgQOjO9xc OMO970IgfjRXCZNgq6A7EAU5b0Vip1E1q9mVbPi+Qh3sdoZd8SY1IU/2OdPVnxgAY5+G Ar5trUq0c0F8yvj3aJroRfch4nSD0Q4j0y8gCgJ9ZPgL3HW6FMToknWWZHCjYKqwAwB+ +dXQ== X-Gm-Message-State: ALoCoQl+Hj7OAng/2470BuLVIcmpoZxBhCbslA0PtBTMbs6JyGPsxyDG/FK+SfBwp7EUFN115pqr X-Received: by 10.220.195.196 with SMTP id ed4mr3011629vcb.65.1413912702033; Tue, 21 Oct 2014 10:31:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.173.136 with HTTP; Tue, 21 Oct 2014 10:31:01 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Tue, 21 Oct 2014 10:31:01 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c1c3245946dd0505f234d1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZTmRG8dOCr4pgDlwX2WlS5j6qcA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 17:31:46 -0000 --001a11c1c3245946dd0505f234d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 345259865 is "real" 2693756249 is rtx On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo wr= ote: > Hi, > > May I know which SSRC (345259865 or 2693756249) will be used for the > real media stream (plus RED and FEC) and which SSRC will be used for > RTX? > > > > -------------------------- > m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 > a=3Dmid:video > a=3Drtpmap:100 VP8/90000 > a=3Drtpmap:116 red/90000 > a=3Drtpmap:117 ulpfec/90000 > a=3Drtpmap:96 rtx/90000 > a=3Dfmtp:96 apt=3D100 > a=3Dssrc-group:FID 345259865 2693756249 > a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs > a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs > a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > ------------------------------- > > > > > RFC 5576 does not clarify it at all: > > http://tools.ietf.org/html/rfc5576#section-4.2 > > -------------------------------------------------- > 4.2. The "ssrc-group" Media Attribute > > a=3Dssrc-group: ... > > [..] > > The parameter is taken from the specification of the > "group" attribute [RFC3388]. The initial semantic values defined for > the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] > and FEC (Forward Error Correction) [RFC4756]. In each case, the > relationship among the grouped sources is the same as the > relationship among corresponding sources in media streams grouped > using the SDP "group" attribute. > -------------------------------------------------- > > > > The referenced RFC 3388 neither clarifies it: > > --------------------------------------------------- > 7.4 FID Semantics > > Several "m" lines grouped together using FID semantics form a media > flow. A media agent handling a media flow that comprises several "m" > lines MUST send a copy of the media to every "m" line part of the > flow as long as the codecs and the direction attribute present in a > particular "m" line allow it. > > It is assumed that the application uses only one codec at a time to > encode the media produced. This codec MAY change dynamically during > the session, but at any particular moment only one codec is in use. > > The application encodes the media using the current codec and checks > one by one all the "m" lines that are part of the flow. If a > particular "m" line contains the codec being used and the direction > attribute is "sendonly" or "sendrecv", a copy of the encoded media is > sent to the address/port specified in that particular media stream. > If either the "m" line does not contain the codec being used or the > direction attribute is neither "sendonly" nor "sendrecv", nothing is > sent over this media stream. > ---------------------------------------------------- > > > > > So, how is the usage of ssrc-group? Where is it really defined? > > Can I put more than 2 ssrc together in the same ssrc-group line? > > How should the receiver interpret it? > > Does a ssrc-group always mean RTX usage? Where is that specified in > the above SDP? > > Does not the above SDP look a complete mixture of hacks and workarounds? > > > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c1c3245946dd0505f234d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
345259865 is "real"
2693756249 is rtx=

On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net<= /a>> wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.=C2=A0 The "ssrc-group" Media Attribute

=C2=A0 =C2=A0a=3Dssrc-group:<semantics> <ssrc-id> ...

=C2=A0 =C2=A0[..]

=C2=A0 =C2=A0The <semantics> parameter is taken from the specificatio= n of the
=C2=A0 =C2=A0"group" attribute [RFC3388].=C2=A0 The initial seman= tic values defined for
=C2=A0 =C2=A0the "ssrc-group" attribute are FID (Flow Identificat= ion) [RFC3388]
=C2=A0 =C2=A0and FEC (Forward Error Correction) [RFC4756].=C2=A0 In each ca= se, the
=C2=A0 =C2=A0relationship among the grouped sources is the same as the
=C2=A0 =C2=A0relationship among corresponding sources in media streams grou= ped
=C2=A0 =C2=A0using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

=C2=A0 =C2=A0Several "m" lines grouped together using FID semanti= cs form a media
=C2=A0 =C2=A0flow.=C2=A0 A media agent handling a media flow that comprises= several "m"
=C2=A0 =C2=A0lines MUST send a copy of the media to every "m" lin= e part of the
=C2=A0 =C2=A0flow as long as the codecs and the direction attribute present= in a
=C2=A0 =C2=A0particular "m" line allow it.

=C2=A0 =C2=A0It is assumed that the application uses only one codec at a ti= me to
=C2=A0 =C2=A0encode the media produced.=C2=A0 This codec MAY change dynamic= ally during
=C2=A0 =C2=A0the session, but at any particular moment only one codec is in= use.

=C2=A0 =C2=A0The application encodes the media using the current codec and = checks
=C2=A0 =C2=A0one by one all the "m" lines that are part of the fl= ow.=C2=A0 If a
=C2=A0 =C2=A0particular "m" line contains the codec being used an= d the direction
=C2=A0 =C2=A0attribute is "sendonly" or "sendrecv", a c= opy of the encoded media is
=C2=A0 =C2=A0sent to the address/port specified in that particular media st= ream.
=C2=A0 =C2=A0If either the "m" line does not contain the codec be= ing used or the
=C2=A0 =C2=A0direction attribute is neither "sendonly" nor "= sendrecv", nothing is
=C2=A0 =C2=A0sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

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

--001a11c1c3245946dd0505f234d1-- From nobody Tue Oct 21 10:40:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78F71A6EE7 for ; Tue, 21 Oct 2014 10:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjun0JT_ZogB for ; Tue, 21 Oct 2014 10:40:47 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F113B1A1AF0 for ; Tue, 21 Oct 2014 10:40:46 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so1352246qcz.37 for ; Tue, 21 Oct 2014 10:40:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ISaS5dE1zpOheedc4eOL6axHhWPMJKxadsXXZGf+txg=; b=bauVk/Ok/0ZX7GUNj0CqkUCOY12E9Q3Zr72x3cbVqAAOGuOz321lEa5Ao3iv1SvCe4 z9EHEIQOAH24zZl5YuZiPK7pTIxsrEihjrqqucDaaXZFUtUm3u2Cy8N1QkwUgTeyZYn8 uocgWiajiJzv7DW0dqYPTX2gIuq94ZVaiQnEOmjEPVTehwj4kVvc8H/NDQv2NI8pHV6U 7YkJCrBlQ6qoxi6myB9F2smYNRcglK7b/l5e3Wea2RU/Atbe03hZqFN1sxSeRTMRJQXS HxuBT0HoQAMvSyaKnWCgk7hhoP7OoyOXOY8vGhAdWTGTZ5YVqB6WLyIZU+WEK858lJBF AefA== X-Gm-Message-State: ALoCoQn/qmbuEAbrw7xfssbxMmArDhTBOZdHooECICU8RcKtEUyasxObPZvNsmmHcg9lN1z+Ngju MIME-Version: 1.0 X-Received: by 10.224.131.8 with SMTP id v8mr48139208qas.6.1413913246119; Tue, 21 Oct 2014 10:40:46 -0700 (PDT) Received: by 10.96.69.200 with HTTP; Tue, 21 Oct 2014 10:40:46 -0700 (PDT) Received: by 10.96.69.200 with HTTP; Tue, 21 Oct 2014 10:40:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Oct 2014 19:40:46 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Peter Thatcher Content-Type: multipart/alternative; boundary=047d7b624e72c76d2e0505f25493 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H7qffB_KuY8m1GpW_FvwoCVjziE Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 17:40:49 -0000 --047d7b624e72c76d2e0505f25493 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How is that? Where is that specified? What about if I include 3 ssrc values in the ssrc-group? What is each one for? On 21 Oct 2014 19:31, "Peter Thatcher" wrote: > 345259865 is "real" > 2693756249 is rtx > > On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo = wrote: > >> Hi, >> >> May I know which SSRC (345259865 or 2693756249) will be used for the >> real media stream (plus RED and FEC) and which SSRC will be used for >> RTX? >> >> >> >> -------------------------- >> m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 >> a=3Dmid:video >> a=3Drtpmap:100 VP8/90000 >> a=3Drtpmap:116 red/90000 >> a=3Drtpmap:117 ulpfec/90000 >> a=3Drtpmap:96 rtx/90000 >> a=3Dfmtp:96 apt=3D100 >> a=3Dssrc-group:FID 345259865 2693756249 >> a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs >> a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >> c0134f05-e7c2-4afd-a979-4e224de5eb91 >> a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >> a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >> a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs >> a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >> c0134f05-e7c2-4afd-a979-4e224de5eb91 >> a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >> a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >> ------------------------------- >> >> >> >> >> RFC 5576 does not clarify it at all: >> >> http://tools.ietf.org/html/rfc5576#section-4.2 >> >> -------------------------------------------------- >> 4.2. The "ssrc-group" Media Attribute >> >> a=3Dssrc-group: ... >> >> [..] >> >> The parameter is taken from the specification of the >> "group" attribute [RFC3388]. The initial semantic values defined for >> the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] >> and FEC (Forward Error Correction) [RFC4756]. In each case, the >> relationship among the grouped sources is the same as the >> relationship among corresponding sources in media streams grouped >> using the SDP "group" attribute. >> -------------------------------------------------- >> >> >> >> The referenced RFC 3388 neither clarifies it: >> >> --------------------------------------------------- >> 7.4 FID Semantics >> >> Several "m" lines grouped together using FID semantics form a media >> flow. A media agent handling a media flow that comprises several "m" >> lines MUST send a copy of the media to every "m" line part of the >> flow as long as the codecs and the direction attribute present in a >> particular "m" line allow it. >> >> It is assumed that the application uses only one codec at a time to >> encode the media produced. This codec MAY change dynamically during >> the session, but at any particular moment only one codec is in use. >> >> The application encodes the media using the current codec and checks >> one by one all the "m" lines that are part of the flow. If a >> particular "m" line contains the codec being used and the direction >> attribute is "sendonly" or "sendrecv", a copy of the encoded media is >> sent to the address/port specified in that particular media stream. >> If either the "m" line does not contain the codec being used or the >> direction attribute is neither "sendonly" nor "sendrecv", nothing is >> sent over this media stream. >> ---------------------------------------------------- >> >> >> >> >> So, how is the usage of ssrc-group? Where is it really defined? >> >> Can I put more than 2 ssrc together in the same ssrc-group line? >> >> How should the receiver interpret it? >> >> Does a ssrc-group always mean RTX usage? Where is that specified in >> the above SDP? >> >> Does not the above SDP look a complete mixture of hacks and workarounds? >> >> >> >> >> -- >> I=C3=B1aki Baz Castillo >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --047d7b624e72c76d2e0505f25493 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

How is that? Where is that specified? What about if I includ= e 3 ssrc values in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher"= <pthatcher@google.com> w= rote:
345259865 is "real"
2693756249 is rtx

On Tue, Oct 21= , 2014 at 9:25 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote= :
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.=C2=A0 The "ssrc-group" Media Attribute

=C2=A0 =C2=A0a=3Dssrc-group:<semantics> <ssrc-id> ...

=C2=A0 =C2=A0[..]

=C2=A0 =C2=A0The <semantics> parameter is taken from the specificatio= n of the
=C2=A0 =C2=A0"group" attribute [RFC3388].=C2=A0 The initial seman= tic values defined for
=C2=A0 =C2=A0the "ssrc-group" attribute are FID (Flow Identificat= ion) [RFC3388]
=C2=A0 =C2=A0and FEC (Forward Error Correction) [RFC4756].=C2=A0 In each ca= se, the
=C2=A0 =C2=A0relationship among the grouped sources is the same as the
=C2=A0 =C2=A0relationship among corresponding sources in media streams grou= ped
=C2=A0 =C2=A0using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

=C2=A0 =C2=A0Several "m" lines grouped together using FID semanti= cs form a media
=C2=A0 =C2=A0flow.=C2=A0 A media agent handling a media flow that comprises= several "m"
=C2=A0 =C2=A0lines MUST send a copy of the media to every "m" lin= e part of the
=C2=A0 =C2=A0flow as long as the codecs and the direction attribute present= in a
=C2=A0 =C2=A0particular "m" line allow it.

=C2=A0 =C2=A0It is assumed that the application uses only one codec at a ti= me to
=C2=A0 =C2=A0encode the media produced.=C2=A0 This codec MAY change dynamic= ally during
=C2=A0 =C2=A0the session, but at any particular moment only one codec is in= use.

=C2=A0 =C2=A0The application encodes the media using the current codec and = checks
=C2=A0 =C2=A0one by one all the "m" lines that are part of the fl= ow.=C2=A0 If a
=C2=A0 =C2=A0particular "m" line contains the codec being used an= d the direction
=C2=A0 =C2=A0attribute is "sendonly" or "sendrecv", a c= opy of the encoded media is
=C2=A0 =C2=A0sent to the address/port specified in that particular media st= ream.
=C2=A0 =C2=A0If either the "m" line does not contain the codec be= ing used or the
=C2=A0 =C2=A0direction attribute is neither "sendonly" nor "= sendrecv", nothing is
=C2=A0 =C2=A0sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;

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

--047d7b624e72c76d2e0505f25493-- From nobody Tue Oct 21 10:57:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7111A7011 for ; Tue, 21 Oct 2014 10:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZThZ4HRIyPRY for ; Tue, 21 Oct 2014 10:57:55 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4D71A6F64 for ; Tue, 21 Oct 2014 10:57:54 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id hz20so1548171lab.11 for ; Tue, 21 Oct 2014 10:57:52 -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; bh=LSUWbb5Ol3C8o+hbXSXWojl/noXHHaVZOSltifqM0WI=; b=fbwWe6xJsS9yDBT3ApHX6syTqw46B1FD+oO6ZnDRIvtbHMTCdKBrgrMtZ41eEvktrk zAxWwHI9kJA/yZHNwQ4JlEiYrWEbuELln8OivZof9DqOrR3lZIg3lNWECYHLYOuTwvnn bYYMZbTylhQVxcOMIJpcR4kC7cCQw5Ryg2DFNfowJKT+pfNm3LMR8RXD5hOeFrF33WJu 1GMk18TTiy4MExAUTz2/XMKHZwldK20TYLXJpZQ5+9QDFCvsLkwnmGP8xSB5dMb8zlq4 fYmmFN/AEHuSvMcA0GBrKcJ5JSUipO+syoxv43jN4xTq/g/t5pwVJF5WUHfHVXDWIU/a 0apA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LSUWbb5Ol3C8o+hbXSXWojl/noXHHaVZOSltifqM0WI=; b=djkevotfQn63nmBeErrwbaRAQh183u9mD062+Oo/Dcpx2KnAJEfJe/zv2EFBf95mmO 24/ukXuz7ztnpd8AZhhMRe94uMbOAI+KxhWk+CYi+2ZximQZSWh48jB+VCUZYJNPPiri 8xle7Vdb/ooFJe/e0OAAkm4oz9whFnvpMKcVooxDTuRSXsmwnjA6xAk1DcxoX8Ee5YhG w2o5WACEnPmE29LMnKLwVdhFHE8S1+8SChPZLlSyI8Aqjy1bEt4PBZKxaNPAcnpVZD/J o5EnJyNLOcIDnXqC1Zp4SGO51f+yLQ3ZuZ65OqELSPtl1yHYckO7Mf5u7tfcVoLLyvP5 UOVg== X-Gm-Message-State: ALoCoQnac+RIBx4AUpaqgzk9/utbiOCeAADw8sRPGWYIFSvv/7XDbaFRPrjmJoKSAPZhXMNOHEgg X-Received: by 10.152.87.98 with SMTP id w2mr36011375laz.27.1413914270259; Tue, 21 Oct 2014 10:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.203.193 with HTTP; Tue, 21 Oct 2014 10:57:09 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Tue, 21 Oct 2014 10:57:09 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c34bced2842a0505f29196 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H_RmxZTEgVGbWU2VAZ_kxeAoohU Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 17:57:57 -0000 --001a11c34bced2842a0505f29196 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not sure where it's specified, but here's where it's implemented: https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webr= tcvideoengine.cc#4108 It only supports 2 SSRCs for a FID group. It would ignore any more than that. On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo w= rote: > How is that? Where is that specified? What about if I include 3 ssrc > values in the ssrc-group? What is each one for? > On 21 Oct 2014 19:31, "Peter Thatcher" wrote: > >> 345259865 is "real" >> 2693756249 is rtx >> >> On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo >> wrote: >> >>> Hi, >>> >>> May I know which SSRC (345259865 or 2693756249) will be used for the >>> real media stream (plus RED and FEC) and which SSRC will be used for >>> RTX? >>> >>> >>> >>> -------------------------- >>> m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 >>> a=3Dmid:video >>> a=3Drtpmap:100 VP8/90000 >>> a=3Drtpmap:116 red/90000 >>> a=3Drtpmap:117 ulpfec/90000 >>> a=3Drtpmap:96 rtx/90000 >>> a=3Dfmtp:96 apt=3D100 >>> a=3Dssrc-group:FID 345259865 2693756249 >>> a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs >>> a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs >>> a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> ------------------------------- >>> >>> >>> >>> >>> RFC 5576 does not clarify it at all: >>> >>> http://tools.ietf.org/html/rfc5576#section-4.2 >>> >>> -------------------------------------------------- >>> 4.2. The "ssrc-group" Media Attribute >>> >>> a=3Dssrc-group: ... >>> >>> [..] >>> >>> The parameter is taken from the specification of the >>> "group" attribute [RFC3388]. The initial semantic values defined fo= r >>> the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] >>> and FEC (Forward Error Correction) [RFC4756]. In each case, the >>> relationship among the grouped sources is the same as the >>> relationship among corresponding sources in media streams grouped >>> using the SDP "group" attribute. >>> -------------------------------------------------- >>> >>> >>> >>> The referenced RFC 3388 neither clarifies it: >>> >>> --------------------------------------------------- >>> 7.4 FID Semantics >>> >>> Several "m" lines grouped together using FID semantics form a media >>> flow. A media agent handling a media flow that comprises several "m= " >>> lines MUST send a copy of the media to every "m" line part of the >>> flow as long as the codecs and the direction attribute present in a >>> particular "m" line allow it. >>> >>> It is assumed that the application uses only one codec at a time to >>> encode the media produced. This codec MAY change dynamically during >>> the session, but at any particular moment only one codec is in use. >>> >>> The application encodes the media using the current codec and checks >>> one by one all the "m" lines that are part of the flow. If a >>> particular "m" line contains the codec being used and the direction >>> attribute is "sendonly" or "sendrecv", a copy of the encoded media i= s >>> sent to the address/port specified in that particular media stream. >>> If either the "m" line does not contain the codec being used or the >>> direction attribute is neither "sendonly" nor "sendrecv", nothing is >>> sent over this media stream. >>> ---------------------------------------------------- >>> >>> >>> >>> >>> So, how is the usage of ssrc-group? Where is it really defined? >>> >>> Can I put more than 2 ssrc together in the same ssrc-group line? >>> >>> How should the receiver interpret it? >>> >>> Does a ssrc-group always mean RTX usage? Where is that specified in >>> the above SDP? >>> >>> Does not the above SDP look a complete mixture of hacks and workarounds= ? >>> >>> >>> >>> >>> -- >>> I=C3=B1aki Baz Castillo >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> --001a11c34bced2842a0505f29196 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure where it's specified, but here'= ;s where it's implemented:

https://code.google.com/p/webrtc/source/browse/trunk/talk/media= /webrtc/webrtcvideoengine.cc#4108

=
It only supports 2 SSRCs for a FID group.=C2=A0 It would ignore any mor= e than that.

On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo <ibc@a= liax.net> wrote:

How is that? Where is that specified? What about if I include 3 ss= rc values in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher"= <pthatcher@go= ogle.com> wrote:
345259865 is "real"
2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net&g= t; wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.=C2=A0 The "ssrc-group" Media Attribute

=C2=A0 =C2=A0a=3Dssrc-group:<semantics> <ssrc-id> ...

=C2=A0 =C2=A0[..]

=C2=A0 =C2=A0The <semantics> parameter is taken from the specificatio= n of the
=C2=A0 =C2=A0"group" attribute [RFC3388].=C2=A0 The initial seman= tic values defined for
=C2=A0 =C2=A0the "ssrc-group" attribute are FID (Flow Identificat= ion) [RFC3388]
=C2=A0 =C2=A0and FEC (Forward Error Correction) [RFC4756].=C2=A0 In each ca= se, the
=C2=A0 =C2=A0relationship among the grouped sources is the same as the
=C2=A0 =C2=A0relationship among corresponding sources in media streams grou= ped
=C2=A0 =C2=A0using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

=C2=A0 =C2=A0Several "m" lines grouped together using FID semanti= cs form a media
=C2=A0 =C2=A0flow.=C2=A0 A media agent handling a media flow that comprises= several "m"
=C2=A0 =C2=A0lines MUST send a copy of the media to every "m" lin= e part of the
=C2=A0 =C2=A0flow as long as the codecs and the direction attribute present= in a
=C2=A0 =C2=A0particular "m" line allow it.

=C2=A0 =C2=A0It is assumed that the application uses only one codec at a ti= me to
=C2=A0 =C2=A0encode the media produced.=C2=A0 This codec MAY change dynamic= ally during
=C2=A0 =C2=A0the session, but at any particular moment only one codec is in= use.

=C2=A0 =C2=A0The application encodes the media using the current codec and = checks
=C2=A0 =C2=A0one by one all the "m" lines that are part of the fl= ow.=C2=A0 If a
=C2=A0 =C2=A0particular "m" line contains the codec being used an= d the direction
=C2=A0 =C2=A0attribute is "sendonly" or "sendrecv", a c= opy of the encoded media is
=C2=A0 =C2=A0sent to the address/port specified in that particular media st= ream.
=C2=A0 =C2=A0If either the "m" line does not contain the codec be= ing used or the
=C2=A0 =C2=A0direction attribute is neither "sendonly" nor "= sendrecv", nothing is
=C2=A0 =C2=A0sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;

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


--001a11c34bced2842a0505f29196-- From nobody Tue Oct 21 11:09:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0487C1A875A for ; Tue, 21 Oct 2014 11:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD_hYaM_9qcJ for ; Tue, 21 Oct 2014 11:09:42 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06E71A870C for ; Tue, 21 Oct 2014 11:06:34 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id at20so1817675iec.11 for ; Tue, 21 Oct 2014 11:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8BUV/KWpej/eL4gt+HBp90UCC4DtKdTu6Mud86I+qmg=; b=fw95N+GdOTVaCE7xodRvPiBSvAZi3o9gmieD6BT7l7K5K/msszhm2M6T18pEI6esjN XFpuX6ZKo/T6wB4KghBIiKZUNVQrfqeAkjPj0P4MsUnHLX/QeabQN+7LQo8JiJMpuge0 O8BOeEwIa9joXFf5yLfS2yqnSxWgsdMDSE/SkbngYMGATxlU5goElC6ILaOaN3Kue+sf uJz4cV5obsMN1Wmm0RhN9e/cEXlbh51E9FbQIZmgk+yYB6P8+eOLXI0WmE8DOnbZHckE VC6FSjOiWgxNuDfMjUwr0rNcPylJKvptwY//jrPOAqJYa7T3yIj5KJY9QzxyOn+xoBhF t1Vg== X-Received: by 10.42.236.19 with SMTP id ki19mr4351626icb.73.1413914793492; Tue, 21 Oct 2014 11:06:33 -0700 (PDT) Received: from [192.168.1.113] (71-94-170-52.dhcp.knwc.wa.charter.com. [71.94.170.52]) by mx.google.com with ESMTPSA id dx10sm5735081igb.4.2014.10.21.11.06.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 11:06:32 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-FE23762B-EB41-4B42-8E04-2F46DD6C8C36 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12B410) In-Reply-To: Date: Tue, 21 Oct 2014 11:06:31 -0700 Content-Transfer-Encoding: 7bit Message-Id: <3C434F12-46D1-43D1-81F9-D26AAE9ACBD5@gmail.com> References: To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/b6uqCQoQtHRozUBT-TKn5y6iq-g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 18:09:45 -0000 --Apple-Mail-FE23762B-EB41-4B42-8E04-2F46DD6C8C36 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Looking at the SDP, the Payload Type seems like the clearest way to differen= tiate. As it is, SSRC does not appear linked to the potential payloads. > On Oct 21, 2014, at 10:40 AM, I=C3=B1aki Baz Castillo wrot= e: >=20 > How is that? Where is that specified? What about if I include 3 ssrc value= s in the ssrc-group? What is each one for? >=20 >> On 21 Oct 2014 19:31, "Peter Thatcher" wrote: >> 345259865 is "real" >> 2693756249 is rtx >>=20 >>> On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo = wrote: >>> Hi, >>>=20 >>> May I know which SSRC (345259865 or 2693756249) will be used for the >>> real media stream (plus RED and FEC) and which SSRC will be used for >>> RTX? >>>=20 >>>=20 >>>=20 >>> -------------------------- >>> m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 >>> a=3Dmid:video >>> a=3Drtpmap:100 VP8/90000 >>> a=3Drtpmap:116 red/90000 >>> a=3Drtpmap:117 ulpfec/90000 >>> a=3Drtpmap:96 rtx/90000 >>> a=3Dfmtp:96 apt=3D100 >>> a=3Dssrc-group:FID 345259865 2693756249 >>> a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs >>> a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs >>> a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> ------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 >>> RFC 5576 does not clarify it at all: >>>=20 >>> http://tools.ietf.org/html/rfc5576#section-4.2 >>>=20 >>> -------------------------------------------------- >>> 4.2. The "ssrc-group" Media Attribute >>>=20 >>> a=3Dssrc-group: ... >>>=20 >>> [..] >>>=20 >>> The parameter is taken from the specification of the >>> "group" attribute [RFC3388]. The initial semantic values defined for= >>> the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] >>> and FEC (Forward Error Correction) [RFC4756]. In each case, the >>> relationship among the grouped sources is the same as the >>> relationship among corresponding sources in media streams grouped >>> using the SDP "group" attribute. >>> -------------------------------------------------- >>>=20 >>>=20 >>>=20 >>> The referenced RFC 3388 neither clarifies it: >>>=20 >>> --------------------------------------------------- >>> 7.4 FID Semantics >>>=20 >>> Several "m" lines grouped together using FID semantics form a media >>> flow. A media agent handling a media flow that comprises several "m"= >>> lines MUST send a copy of the media to every "m" line part of the >>> flow as long as the codecs and the direction attribute present in a >>> particular "m" line allow it. >>>=20 >>> It is assumed that the application uses only one codec at a time to >>> encode the media produced. This codec MAY change dynamically during >>> the session, but at any particular moment only one codec is in use. >>>=20 >>> The application encodes the media using the current codec and checks >>> one by one all the "m" lines that are part of the flow. If a >>> particular "m" line contains the codec being used and the direction >>> attribute is "sendonly" or "sendrecv", a copy of the encoded media is= >>> sent to the address/port specified in that particular media stream. >>> If either the "m" line does not contain the codec being used or the >>> direction attribute is neither "sendonly" nor "sendrecv", nothing is >>> sent over this media stream. >>> ---------------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 >>> So, how is the usage of ssrc-group? Where is it really defined? >>>=20 >>> Can I put more than 2 ssrc together in the same ssrc-group line? >>>=20 >>> How should the receiver interpret it? >>>=20 >>> Does a ssrc-group always mean RTX usage? Where is that specified in >>> the above SDP? >>>=20 >>> Does not the above SDP look a complete mixture of hacks and workarounds?= >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> I=C3=B1aki Baz Castillo >>> >>>=20 >>> _______________________________________________ >>> 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 --Apple-Mail-FE23762B-EB41-4B42-8E04-2F46DD6C8C36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Looking at the SDP, the Payload Type s= eems like the clearest way to differentiate.  As it is, SSRC does not a= ppear linked to the potential payloads.



On Oct 21,= 2014, at 10:40 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

How is that? Where is that specified? What about if I inclu= de 3 ssrc values in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher" <pthatcher@google.com> wrote:
345259865 is "= real"
2693756249 is rtx
<= br>
On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Ba= z Castillo <ibc@aliax.net> wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.  The "ssrc-group" Media Attribute

   a=3Dssrc-group:<semantics> <ssrc-id> ...

   [..]

   The <semantics> parameter is taken from the specification= of the
   "group" attribute [RFC3388].  The initial semantic values d= efined for
   the "ssrc-group" attribute are FID (Flow Identification) [RFC33= 88]
   and FEC (Forward Error Correction) [RFC4756].  In each cas= e, the
   relationship among the grouped sources is the same as the
   relationship among corresponding sources in media streams group= ed
   using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

   Several "m" lines grouped together using FID semantics form a m= edia
   flow.  A media agent handling a media flow that comprises s= everal "m"
   lines MUST send a copy of the media to every "m" line part of t= he
   flow as long as the codecs and the direction attribute present i= n a
   particular "m" line allow it.

   It is assumed that the application uses only one codec at a tim= e to
   encode the media produced.  This codec MAY change dynamica= lly during
   the session, but at any particular moment only one codec is in u= se.

   The application encodes the media using the current codec and c= hecks
   one by one all the "m" lines that are part of the flow.  I= f a
   particular "m" line contains the codec being used and the direc= tion
   attribute is "sendonly" or "sendrecv", a copy of the encoded me= dia is
   sent to the address/port specified in that particular media str= eam.
   If either the "m" line does not contain the codec being used or= the
   direction attribute is neither "sendonly" nor "sendrecv", nothi= ng is
   sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?
=



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>=

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

____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-FE23762B-EB41-4B42-8E04-2F46DD6C8C36-- From nobody Tue Oct 21 11:31:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F031A7014 for ; Tue, 21 Oct 2014 11:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InialMaiWZv6 for ; Tue, 21 Oct 2014 11:31:33 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7941A6F07 for ; Tue, 21 Oct 2014 11:31:29 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id fb4so2674282wid.16 for ; Tue, 21 Oct 2014 11:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=244HTTvADDjimvCkPdVl9kfF5zTHWPK/IB6kLRSfvKI=; b=Cj5F/nJHTFhScYUCbdbPYQrV6O1RiO/LWVrEhJdHklrgrOOunrTh4JnHxSi7Y98GKs z+S8pjGVgwUbfCVK71LZnxbbZlltBmrSXOrtg+0CsFHPu/thNpvuR/YtJ8/ibBh82B2z GieUAFF5fD30kTASickshPW9saXCYmhWn7AQzhDQQNS86UA0qaS+A2QJ3FwSSYHH+RAT P57ruCwGXEfWDHksElbwiCI9NQqreO9XgK1rnItfNNUwBUA/hT9lj2sTtDP1hK8cKV9o v/IYwNeOExpj/BWOnnWxgZaCI54Sue7U0we/9nUspoux1VpuTNxVDIjChqvwDHSVvyUg mugg== X-Received: by 10.194.24.98 with SMTP id t2mr20647724wjf.24.1413916284641; Tue, 21 Oct 2014 11:31:24 -0700 (PDT) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id ga7sm13948792wic.5.2014.10.21.11.31.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 11:31:23 -0700 (PDT) Message-ID: <5446A67E.9010306@gmail.com> Date: Tue, 21 Oct 2014 20:31:26 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060203090304080301040400" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MnTf8WHcfgvIZ_GY3m_cNug54Io Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 18:31:36 -0000 This is a multi-part message in MIME format. --------------060203090304080301040400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Peter, This is the rtcweb list, so while I appreciate the info about how Chrome implements it, in regards to this discussion it is irrelevant. As far as I know there is no spec that allow us to know just by looking at the SDP which ssrc belongs to each stream. Please, correct me if I am wrong. Best regards Sergio On 21/10/2014 19:57, Peter Thatcher wrote: > I'm not sure where it's specified, but here's where it's implemented: > > https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengine.cc#4108 > > It only supports 2 SSRCs for a FID group. It would ignore any more > than that. > > On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo > wrote: > > How is that? Where is that specified? What about if I include 3 > ssrc values in the ssrc-group? What is each one for? > > On 21 Oct 2014 19:31, "Peter Thatcher" > wrote: > > 345259865 is "real" > 2693756249 is rtx > > On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo > > wrote: > > Hi, > > May I know which SSRC (345259865 or 2693756249 > ) will be used for the > real media stream (plus RED and FEC) and which SSRC will > be used for > RTX? > > > > -------------------------- > m=video 62164 RTP/SAVPF 100 116 117 96 > a=mid:video > a=rtpmap:100 VP8/90000 > a=rtpmap:116 red/90000 > a=rtpmap:117 ulpfec/90000 > a=rtpmap:96 rtx/90000 > a=fmtp:96 apt=100 > a=ssrc-group:FID 345259865 2693756249 > a=ssrc:345259865 cname:erS7E/KHLYKTejNs > a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=ssrc:2693756249 cname:erS7E/KHLYKTejNs > a=ssrc:2693756249 > msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=ssrc:2693756249 > mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=ssrc:2693756249 > label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > ------------------------------- > > > > > RFC 5576 does not clarify it at all: > > http://tools.ietf.org/html/rfc5576#section-4.2 > > -------------------------------------------------- > 4.2. The "ssrc-group" Media Attribute > > a=ssrc-group: ... > > [..] > > The parameter is taken from the > specification of the > "group" attribute [RFC3388]. The initial semantic > values defined for > the "ssrc-group" attribute are FID (Flow > Identification) [RFC3388] > and FEC (Forward Error Correction) [RFC4756]. In each > case, the > relationship among the grouped sources is the same as the > relationship among corresponding sources in media > streams grouped > using the SDP "group" attribute. > -------------------------------------------------- > > > > The referenced RFC 3388 neither clarifies it: > > --------------------------------------------------- > 7.4 FID Semantics > > Several "m" lines grouped together using FID semantics > form a media > flow. A media agent handling a media flow that > comprises several "m" > lines MUST send a copy of the media to every "m" line > part of the > flow as long as the codecs and the direction attribute > present in a > particular "m" line allow it. > > It is assumed that the application uses only one codec > at a time to > encode the media produced. This codec MAY change > dynamically during > the session, but at any particular moment only one > codec is in use. > > The application encodes the media using the current > codec and checks > one by one all the "m" lines that are part of the > flow. If a > particular "m" line contains the codec being used and > the direction > attribute is "sendonly" or "sendrecv", a copy of the > encoded media is > sent to the address/port specified in that particular > media stream. > If either the "m" line does not contain the codec being > used or the > direction attribute is neither "sendonly" nor > "sendrecv", nothing is > sent over this media stream. > ---------------------------------------------------- > > > > > So, how is the usage of ssrc-group? Where is it really > defined? > > Can I put more than 2 ssrc together in the same ssrc-group > line? > > How should the receiver interpret it? > > Does a ssrc-group always mean RTX usage? Where is that > specified in > the above SDP? > > Does not the above SDP look a complete mixture of hacks > and workarounds? > > > > > -- > Iñaki Baz Castillo > > > > _______________________________________________ > 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 --------------060203090304080301040400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Peter,

This is the rtcweb list, so while I appreciate the info about how Chrome implements it, in regards to this discussion it is irrelevant. As far as I know there is no spec that allow us to know just by looking at the SDP which ssrc belongs to each stream. Please, correct me if I am wrong.

Best regards
Sergio
On 21/10/2014 19:57, Peter Thatcher wrote:
I'm not sure where it's specified, but here's where it's implemented:

https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengine.cc#4108

It only supports 2 SSRCs for a FID group.  It would ignore any more than that.

On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

How is that? Where is that specified? What about if I include 3 ssrc values in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher" <pthatcher@google.com> wrote:
345259865 is "real"
2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=video 62164 RTP/SAVPF 100 116 117 96
a=mid:video
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=ssrc-group:FID 345259865 2693756249
a=ssrc:345259865 cname:erS7E/KHLYKTejNs
a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249 cname:erS7E/KHLYKTejNs
a=ssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.  The "ssrc-group" Media Attribute

   a=ssrc-group:<semantics> <ssrc-id> ...

   [..]

   The <semantics> parameter is taken from the specification of the
   "group" attribute [RFC3388].  The initial semantic values defined for
   the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
   and FEC (Forward Error Correction) [RFC4756].  In each case, the
   relationship among the grouped sources is the same as the
   relationship among corresponding sources in media streams grouped
   using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

   Several "m" lines grouped together using FID semantics form a media
   flow.  A media agent handling a media flow that comprises several "m"
   lines MUST send a copy of the media to every "m" line part of the
   flow as long as the codecs and the direction attribute present in a
   particular "m" line allow it.

   It is assumed that the application uses only one codec at a time to
   encode the media produced.  This codec MAY change dynamically during
   the session, but at any particular moment only one codec is in use.

   The application encodes the media using the current codec and checks
   one by one all the "m" lines that are part of the flow.  If a
   particular "m" line contains the codec being used and the direction
   attribute is "sendonly" or "sendrecv", a copy of the encoded media is
   sent to the address/port specified in that particular media stream.
   If either the "m" line does not contain the codec being used or the
   direction attribute is neither "sendonly" nor "sendrecv", nothing is
   sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?




--
Iñaki Baz Castillo
<ibc@aliax.net>

_______________________________________________
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

--------------060203090304080301040400-- From nobody Tue Oct 21 11:36:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64D1A87C2 for ; Tue, 21 Oct 2014 11:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ9MVNfRtBFP for ; Tue, 21 Oct 2014 11:36:20 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26DB1A1BCA for ; Tue, 21 Oct 2014 11:36:19 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id i13so1305693qae.13 for ; Tue, 21 Oct 2014 11:36:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rumHtznVX2qMgKNsDPzO+MrD3a0XMl9zUH2uXAG01ZU=; b=Br7tF/mM5bw9AvW4s7ZRkQuzlZyASQJ2uQ2p/E6tF0EGeN10uM+yicubzZzs9iQq15 pjDwT0hrPQNXazVG+FBh6yRe/UPT6fsrPZghmfJCFQxjzSOC3eT/xaaBaT/1wwtyPaxW kGFYRjK0E/uhEdGrcScQM3ZzAj8U4haEBoZOG4/uFULSDw+5mG2mbLmUz9TYXf6Ilmwu yUQ/c04Qeb6WfasejwycSHPZwOGxx8HW9gduFaZaBfmcRUPArASlZT7TxMz7/yoEZHkV UPDeA06Iw/YGfMOvuSy+3znHi5bFvjd48aY7uGRECovIwhLTs36aY/XnpSSwrMTymH3V DNdw== X-Gm-Message-State: ALoCoQll91pyKfLm/OhlAyFu+9VwXSB8ApbQ1iUSN+ectkzVBN6fKCuw8tCn/j8WOFrtQ736KRlA MIME-Version: 1.0 X-Received: by 10.229.247.200 with SMTP id md8mr48105471qcb.7.1413916576832; Tue, 21 Oct 2014 11:36:16 -0700 (PDT) Received: by 10.96.69.200 with HTTP; Tue, 21 Oct 2014 11:36:16 -0700 (PDT) Received: by 10.96.69.200 with HTTP; Tue, 21 Oct 2014 11:36:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Oct 2014 20:36:16 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a1134a5ca4df8110505f31b86 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KcqBMEiY-sLy0kCjEGwdZo9YqJI Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 18:36:22 -0000 --001a1134a5ca4df8110505f31b86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I hope I can rule my SDP logic based on standards rather than on how Chrome implements some features. My question was generic: if I receive the above SDP, how do I know which payloads each ssrc is supposed to transport? On 21 Oct 2014 19:57, "Peter Thatcher" wrote: > I'm not sure where it's specified, but here's where it's implemented: > > > https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/we= brtcvideoengine.cc#4108 > > It only supports 2 SSRCs for a FID group. It would ignore any more than > that. > > On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo > wrote: > >> How is that? Where is that specified? What about if I include 3 ssrc >> values in the ssrc-group? What is each one for? >> On 21 Oct 2014 19:31, "Peter Thatcher" wrote: >> >>> 345259865 is "real" >>> 2693756249 is rtx >>> >>> On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo >>> wrote: >>> >>>> Hi, >>>> >>>> May I know which SSRC (345259865 or 2693756249) will be used for the >>>> real media stream (plus RED and FEC) and which SSRC will be used for >>>> RTX? >>>> >>>> >>>> >>>> -------------------------- >>>> m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 >>>> a=3Dmid:video >>>> a=3Drtpmap:100 VP8/90000 >>>> a=3Drtpmap:116 red/90000 >>>> a=3Drtpmap:117 ulpfec/90000 >>>> a=3Drtpmap:96 rtx/90000 >>>> a=3Dfmtp:96 apt=3D100 >>>> a=3Dssrc-group:FID 345259865 2693756249 >>>> a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs >>>> a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>> a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>> a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>> a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs >>>> a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>> a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>> a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>> ------------------------------- >>>> >>>> >>>> >>>> >>>> RFC 5576 does not clarify it at all: >>>> >>>> http://tools.ietf.org/html/rfc5576#section-4.2 >>>> >>>> -------------------------------------------------- >>>> 4.2. The "ssrc-group" Media Attribute >>>> >>>> a=3Dssrc-group: ... >>>> >>>> [..] >>>> >>>> The parameter is taken from the specification of the >>>> "group" attribute [RFC3388]. The initial semantic values defined f= or >>>> the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] >>>> and FEC (Forward Error Correction) [RFC4756]. In each case, the >>>> relationship among the grouped sources is the same as the >>>> relationship among corresponding sources in media streams grouped >>>> using the SDP "group" attribute. >>>> -------------------------------------------------- >>>> >>>> >>>> >>>> The referenced RFC 3388 neither clarifies it: >>>> >>>> --------------------------------------------------- >>>> 7.4 FID Semantics >>>> >>>> Several "m" lines grouped together using FID semantics form a media >>>> flow. A media agent handling a media flow that comprises several "= m" >>>> lines MUST send a copy of the media to every "m" line part of the >>>> flow as long as the codecs and the direction attribute present in a >>>> particular "m" line allow it. >>>> >>>> It is assumed that the application uses only one codec at a time to >>>> encode the media produced. This codec MAY change dynamically durin= g >>>> the session, but at any particular moment only one codec is in use. >>>> >>>> The application encodes the media using the current codec and check= s >>>> one by one all the "m" lines that are part of the flow. If a >>>> particular "m" line contains the codec being used and the direction >>>> attribute is "sendonly" or "sendrecv", a copy of the encoded media = is >>>> sent to the address/port specified in that particular media stream. >>>> If either the "m" line does not contain the codec being used or the >>>> direction attribute is neither "sendonly" nor "sendrecv", nothing i= s >>>> sent over this media stream. >>>> ---------------------------------------------------- >>>> >>>> >>>> >>>> >>>> So, how is the usage of ssrc-group? Where is it really defined? >>>> >>>> Can I put more than 2 ssrc together in the same ssrc-group line? >>>> >>>> How should the receiver interpret it? >>>> >>>> Does a ssrc-group always mean RTX usage? Where is that specified in >>>> the above SDP? >>>> >>>> Does not the above SDP look a complete mixture of hacks and workaround= s? >>>> >>>> >>>> >>>> >>>> -- >>>> I=C3=B1aki Baz Castillo >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >>> > --001a1134a5ca4df8110505f31b86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I hope I can rule my SDP logic based on standards rather tha= n on how Chrome implements some features.

My question was generic: if I receive the above SDP, how do = I know which payloads each ssrc is supposed to transport?

On 21 Oct 2014 19:57, "Peter Thatcher"= <pthatcher@google.com> w= rote:
I'm not sure where it's specified, but here's where it= 9;s implemented:

https://code.google.com/p/webrtc/source/browse/trunk/talk/media= /webrtc/webrtcvideoengine.cc#4108

It only = supports 2 SSRCs for a FID group.=C2=A0 It would ignore any more than that.=

On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net= > wrote:

How is = that? Where is that specified? What about if I include 3 ssrc values in the= ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher"= <pthatcher@go= ogle.com> wrote:
345259865 is "real"
2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net&g= t; wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.=C2=A0 The "ssrc-group" Media Attribute

=C2=A0 =C2=A0a=3Dssrc-group:<semantics> <ssrc-id> ...

=C2=A0 =C2=A0[..]

=C2=A0 =C2=A0The <semantics> parameter is taken from the specificatio= n of the
=C2=A0 =C2=A0"group" attribute [RFC3388].=C2=A0 The initial seman= tic values defined for
=C2=A0 =C2=A0the "ssrc-group" attribute are FID (Flow Identificat= ion) [RFC3388]
=C2=A0 =C2=A0and FEC (Forward Error Correction) [RFC4756].=C2=A0 In each ca= se, the
=C2=A0 =C2=A0relationship among the grouped sources is the same as the
=C2=A0 =C2=A0relationship among corresponding sources in media streams grou= ped
=C2=A0 =C2=A0using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

=C2=A0 =C2=A0Several "m" lines grouped together using FID semanti= cs form a media
=C2=A0 =C2=A0flow.=C2=A0 A media agent handling a media flow that comprises= several "m"
=C2=A0 =C2=A0lines MUST send a copy of the media to every "m" lin= e part of the
=C2=A0 =C2=A0flow as long as the codecs and the direction attribute present= in a
=C2=A0 =C2=A0particular "m" line allow it.

=C2=A0 =C2=A0It is assumed that the application uses only one codec at a ti= me to
=C2=A0 =C2=A0encode the media produced.=C2=A0 This codec MAY change dynamic= ally during
=C2=A0 =C2=A0the session, but at any particular moment only one codec is in= use.

=C2=A0 =C2=A0The application encodes the media using the current codec and = checks
=C2=A0 =C2=A0one by one all the "m" lines that are part of the fl= ow.=C2=A0 If a
=C2=A0 =C2=A0particular "m" line contains the codec being used an= d the direction
=C2=A0 =C2=A0attribute is "sendonly" or "sendrecv", a c= opy of the encoded media is
=C2=A0 =C2=A0sent to the address/port specified in that particular media st= ream.
=C2=A0 =C2=A0If either the "m" line does not contain the codec be= ing used or the
=C2=A0 =C2=A0direction attribute is neither "sendonly" nor "= sendrecv", nothing is
=C2=A0 =C2=A0sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;

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


--001a1134a5ca4df8110505f31b86-- From nobody Tue Oct 21 11:58:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A511A87C3 for ; Tue, 21 Oct 2014 11:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIOVQgKJoisW for ; Tue, 21 Oct 2014 11:58:33 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4BD31A1BC8 for ; Tue, 21 Oct 2014 11:58:32 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id bs8so1937434wib.17 for ; Tue, 21 Oct 2014 11:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=DwdoKfcxVYxMvYkmNf9cgNhQ8rTg8+39IqWfq0G+t8o=; b=fUZyMGjTK9RYvbseZ1mxzuRwE3PreSDGt9jJm6/cD+/kl9ZMcLw019QXRDRdSuJ445 OePkksnrRkFC2mf+YDAahYbg2copwPe4XTE9a0WTmi4xCSFaaEUKQ7OOb4YNE/T1fjWw Osbjvks/MoDEaXGu+k5cr1I/2BVld2lGarqaLl4wxzGNqQFv4VbXli1iwAbOznT1+/U6 2wrEzD9cE6CGZ+AkxkvhRSzVzC+TALI71w1CGCSxzi1q4U+gs6YUbpD3NReY59rirQGu tzZy57loA248SCwurI4A9FQtN3LIb2thStHBiQxg3OI5wGEcj+OSGjI55gS5XQRKBT2x +X+A== X-Received: by 10.194.189.82 with SMTP id gg18mr16636817wjc.115.1413917910133; Tue, 21 Oct 2014 11:58:30 -0700 (PDT) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id t9sm16262351wjf.41.2014.10.21.11.58.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 11:58:29 -0700 (PDT) Message-ID: <5446ACD8.1010004@gmail.com> Date: Tue, 21 Oct 2014 20:58:32 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "" Content-Type: multipart/alternative; boundary="------------020003060701020508050205" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RGcS9my1Z6PCcRruAU1l9dZS-MU Subject: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 18:58:35 -0000 This is a multi-part message in MIME format. --------------020003060701020508050205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side: Receivers are REQUIRED to implement support for RTP retransmission packets [RFC4588 ]. That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense. Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end? Best regards Sergio --------------020003060701020508050205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

Best regards
Sergio
--------------020003060701020508050205-- From nobody Tue Oct 21 13:02:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F3B1A6EDA for ; Tue, 21 Oct 2014 13:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnB6VO-BlDGL for ; Tue, 21 Oct 2014 13:02:50 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8FA1A6ED9 for ; Tue, 21 Oct 2014 13:02:50 -0700 (PDT) Received: by mail-oi0-f42.google.com with SMTP id a141so1607380oig.29 for ; Tue, 21 Oct 2014 13:02:49 -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; bh=2G0SSDkOvL2/BYX+lRt5xZ1LpQEGKhiJ5BKPF4SQdCA=; b=UrugMTs+jO31vF9MgcZNvT9IVg/FXALBzDMJqLZVuCg7/UKaTOjK/xrsBRWTFvXFg3 nygw+pANcFyJMK5l+GIoomBHR13BShA/m3w1FewnVcL0DhJYrhm11SiWhnYp6OBZK3M4 nXxAplwVFoKvrRBoFMAbMqlOY8FW0pp8REwg7e+VA8Ffz37CWXPQREn0ZhE5e0UeR+iH FuWePms77wKQMxxPt4Ae9bdHjhNoye//7O81r0xXyqRjrG5c3qyzIgNQm15Ton6E+wGK 4brFV5iKPh5dNR4vonil9+vKpX+dt1+1hVduKzXdry9yJO6cVtg0Efuqx0wx1Ph8Og/k pCAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2G0SSDkOvL2/BYX+lRt5xZ1LpQEGKhiJ5BKPF4SQdCA=; b=P86x+TuW8IsffpBKq9Y9EA2jWt8dDK3wBC9tsEGOmLsxeg6FuE/Ii0fj7SJCyt+dAi 3VpDntuLMkdF6O6pQ43RWm+lP0O6AGJv5LMYfzJrEhleM4fmOc6EMQRh8ycLbcbjbyf5 +1rPWz6PW2kvetdGx3L9q0fqbE8gwglw+M31IByVQyErW6GaPsJwpydYL6BPU9D3DqLy 9Sm3dE1u65mo9cuyL+zxhjercVrmfOEDCo9sjNAPwkyQT+b0NCoqzDJ7Vfhz3zqThJwx GXsehSckErEv4NyxwAHRzElUNqfB+fpk3+ZwIihe2bmjlLh+mVkWn2WAr/S/KnvgnSSY sLUA== X-Gm-Message-State: ALoCoQnD4spL1ny6tpIeCuZ8ZS8K81NwVVCnGTGfEM1y/4e9GG2WU3/fbXRRXlPQqyA9zLhBZwRe X-Received: by 10.182.19.228 with SMTP id i4mr16397978obe.38.1413921769528; Tue, 21 Oct 2014 13:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.251.230 with HTTP; Tue, 21 Oct 2014 13:02:29 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 21 Oct 2014 13:02:29 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c2a28cd0405b0505f450b6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/k2wX1leYlo60Mkqq09HhD1mKOHo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 20:02:52 -0000 --001a11c2a28cd0405b0505f450b6 Content-Type: text/plain; charset=UTF-8 > > > Does not the above SDP look a complete mixture of hacks and workarounds? > > Are you new here? In all seriousness, it would be nice if this behavior was standardized, so that applications could have deterministic behavior. If we can come up with appropriate text about the ordering of SSRCs, this could be written into JSEP's handling of setLocalDescription. --001a11c2a28cd0405b0505f450b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Does not the above SDP look a complete mixture of hacks and workarounds?

Are you new here?=C2=A0

In all seriousness, = it would be nice if this behavior was standardized, so that applications co= uld have deterministic behavior. If we can come up with appropriate text ab= out the ordering of SSRCs, this could be written into JSEP's handling o= f setLocalDescription.
--001a11c2a28cd0405b0505f450b6-- From nobody Tue Oct 21 13:15:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AC41A6F3E for ; Tue, 21 Oct 2014 13:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfjB-yoy4vZ5 for ; Tue, 21 Oct 2014 13:14:57 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BAA1A01F9 for ; Tue, 21 Oct 2014 13:14:25 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 4EF19E44971FB; Tue, 21 Oct 2014 20:14:20 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9LKEKGF031872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 16:14:23 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 16:14:23 -0400 From: "Makaraju, Maridi Raju (Raju)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Peter Thatcher Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw7JCgA///BDVA= Date: Tue, 21 Oct 2014 20:14:22 +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: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5EAE2AUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9sevlTAeL3v5d4W15L2U7SnzN1g Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 20:14:58 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5EAE2AUS70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBob3BlIEkgY2FuIHJ1bGUgbXkgU0RQIGxvZ2ljIGJhc2VkIG9uIHN0YW5kYXJkcyByYXRoZXIg dGhhbiBvbiBob3cgQ2hyb21lIGltcGxlbWVudHMgc29tZSBmZWF0dXJlcy4NCg0KTXkgcXVlc3Rp b24gd2FzIGdlbmVyaWM6IGlmIEkgcmVjZWl2ZSB0aGUgYWJvdmUgU0RQLCBob3cgZG8gSSBrbm93 IHdoaWNoIHBheWxvYWRzIGVhY2ggc3NyYyBpcyBzdXBwb3NlZCB0byB0cmFuc3BvcnQ/DQoNCjxS YWp1ID4NCg0KUmlnaHQuIEZpcmVmb3ggbWF5IGhhdmUgYSBkaWZmZXJlbnQgaW50ZXJwcmV0YXRp b24uDQoNCklmIGE9c3NyYy1ncm91cCBhbmQgcmV0cmFuc21pc3Npb25zIGFyZSBuZWdvdGlhdGVk IGF0IFNEUCBhbnN3ZXIsIHRoZW4gdGhlIG9yZGVyIG9mIHNzcmNzIHByb2JhYmx5IGRvZXMgbm90 IG1hdHRlciBhcyB0aGUgUlRQIHBheWxvYWQgdmFsdWVzIGNhbiBkZXRlcm1pbmUgdGhlIHJldHJh bnNtaXNzaW9uIHZzLiBvcmlnaW5hbCBwYXlsb2Fkcy4NCg0KSWYgYW5zd2VyZXIgd2FudHMgdG8g a25vdyB0aGUgb3JpZ2luYWwgc3NyYyBmb3IgcmVqZWN0aW5nIGE9c3NyYy1ncm91cCBhbmQgcmV0 cmFuc21pc3Npb24gcGF5bG9hZCB0aGVuIGl0IG5lZWQgdG8ga25vdyB0aGUgb3JpZ2luYWwgc3Ny Yy4NCg0KDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1NzYjc2VjdGlvbi02LjMg ZGVmaW5lcyBhPXNzcmMgd2l0aCBmb3JtYXQuIEluIHRoZSBleGFtcGxlIGJlbG93LA0KDQp3b27i gJl0IGhhdmluZyB0aGUgZm9sbG93aW5nIFNEUCBsaW5lIGJlIHN1ZmZpY2llbnQgdG8gYXNzaWdu IDI2OTM3NTYyNDk8dGVsOjI2OTM3NTYyNDk+IGZvciByZXRyYW5zbWlzc2lvbiBhbmQsIGluZGly ZWN0bHksIGFzc2lnbiAgMzQ1MjU5ODY1IGZvciBvcmlnaW5hbCAuDQoNCmE9c3NyYzoyNjkzNzU2 MjQ5PHRlbDoyNjkzNzU2MjQ5PiBmbXRwOjk2DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQptPXZpZGVvIDYyMTY0IFJUUC9TQVZQRiAxMDAgMTE2IDExNyA5Ng0KYT1taWQ6dmlkZW8NCmE9 cnRwbWFwOjEwMCBWUDgvOTAwMDANCmE9cnRwbWFwOjExNiByZWQvOTAwMDANCmE9cnRwbWFwOjEx NyB1bHBmZWMvOTAwMDANCmE9cnRwbWFwOjk2IHJ0eC85MDAwMA0KYT1mbXRwOjk2IGFwdD0xMDAN CmE9c3NyYy1ncm91cDpGSUQgMzQ1MjU5ODY1IDI2OTM3NTYyNDk8dGVsOjI2OTM3NTYyNDk+DQph PXNzcmM6MzQ1MjU5ODY1IGNuYW1lOmVyUzdFL0tITFlLVGVqTnMNCmE9c3NyYzozNDUyNTk4NjUg bXNpZDpEV3BXY3Q5YldLelRNTllabjViS1Znd1o4TWZ5MkV0ZnFCWTUNCmMwMTM0ZjA1LWU3YzIt NGFmZC1hOTc5LTRlMjI0ZGU1ZWI5MQ0KYT1zc3JjOjM0NTI1OTg2NSBtc2xhYmVsOkRXcFdjdDli V0t6VE1OWVpuNWJLVmd3WjhNZnkyRXRmcUJZNQ0KYT1zc3JjOjM0NTI1OTg2NSBsYWJlbDpjMDEz NGYwNS1lN2MyLTRhZmQtYTk3OS00ZTIyNGRlNWViOTENCmE9c3NyYzoyNjkzNzU2MjQ5PHRlbDoy NjkzNzU2MjQ5PiBjbmFtZTplclM3RS9LSExZS1Rlak5zDQphPXNzcmM6MjY5Mzc1NjI0OTx0ZWw6 MjY5Mzc1NjI0OT4gbXNpZDpEV3BXY3Q5YldLelRNTllabjViS1Znd1o4TWZ5MkV0ZnFCWTUNCmMw MTM0ZjA1LWU3YzItNGFmZC1hOTc5LTRlMjI0ZGU1ZWI5MQ0KYT1zc3JjOjI2OTM3NTYyNDk8dGVs OjI2OTM3NTYyNDk+IG1zbGFiZWw6RFdwV2N0OWJXS3pUTU5ZWm41YktWZ3daOE1meTJFdGZxQlk1 DQphPXNzcmM6MjY5Mzc1NjI0OTx0ZWw6MjY5Mzc1NjI0OT4gbGFiZWw6YzAxMzRmMDUtZTdjMi00 YWZkLWE5NzktNGUyMjRkZTVlYjkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Ck9uIHRoZSBxdWVzdGlvbiBvZiB3aGF0IGlmIHRoZXJlIGFyZSAzIHNzcmNzPw0KDQpQZXIgbXkg dW5kZXJzdGFuZGluZywgdGhlcmUgaXMgb25seSBvbmUgc3NyYyBmb3Igb3JpZ2luYWwgcGF5bG9h ZCBhbmQgYW5vdGhlciBmb3IgcmV0cmFuc21pc3Npb24uIFNvLCBhPXNzcmMtZ3JvdXAgY29udGFp bmluZyAzIHNzcmNzIGlzIHByb2JhYmx5IGludmFsaWQuDQoNCg0KDQo8L1JhanU+DQoNCg0KDQpC Ug0KDQpSYWp1DQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E5EAE2AUS70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cD5JIGhvcGUgSSBjYW4gcnVsZSBteSBTRFAgbG9n aWMgYmFzZWQgb24gc3RhbmRhcmRzIHJhdGhlciB0aGFuIG9uIGhvdyBDaHJvbWUgaW1wbGVtZW50 cyBzb21lIGZlYXR1cmVzLjxvOnA+PC9vOnA+PC9wPg0KPHA+TXkgcXVlc3Rpb24gd2FzIGdlbmVy aWM6IGlmIEkgcmVjZWl2ZSB0aGUgYWJvdmUgU0RQLCBob3cgZG8gSSBrbm93IHdoaWNoIHBheWxv YWRzIGVhY2ggc3NyYyBpcyBzdXBwb3NlZCB0byB0cmFuc3BvcnQ/PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZsdDtSYWp1ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJpZ2h0LiBGaXJlZm94IG1heSBo YXZlIGEgZGlmZmVyZW50IGludGVycHJldGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgYT1zc3JjLWdyb3Vw IGFuZCByZXRyYW5zbWlzc2lvbnMgYXJlIG5lZ290aWF0ZWQgYXQgU0RQIGFuc3dlciwgdGhlbiB0 aGUgb3JkZXIgb2Ygc3NyY3MgcHJvYmFibHkgZG9lcyBub3QgbWF0dGVyIGFzIHRoZSBSVFAgcGF5 bG9hZA0KIHZhbHVlcyBjYW4gZGV0ZXJtaW5lIHRoZSByZXRyYW5zbWlzc2lvbiB2cy4gb3JpZ2lu YWwgcGF5bG9hZHMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBhbnN3ZXJlciB3YW50cyB0byBrbm93IHRoZSBvcmln aW5hbCBzc3JjIGZvciByZWplY3RpbmcgYT1zc3JjLWdyb3VwIGFuZCByZXRyYW5zbWlzc2lvbiBw YXlsb2FkIHRoZW4gaXQgbmVlZCB0byBrbm93IHRoZSBvcmlnaW5hbA0KIHNzcmMuPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzU1NzYjc2VjdGlvbi02LjMiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1NzYjc2Vj dGlvbi02LjM8L2E+IGRlZmluZXMgYT1zc3JjIHdpdGgNCiBmb3JtYXQuIEluIHRoZSBleGFtcGxl IGJlbG93LDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+d29u4oCZdCBoYXZpbmcgdGhlIGZvbGxvd2luZyBTRFAgbGluZSBi ZSBzdWZmaWNpZW50IHRvIGFzc2lnbg0KPGEgaHJlZj0idGVsOjI2OTM3NTYyNDkiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ MjY5Mzc1NjI0OTwvc3Bhbj48L2E+IGZvciByZXRyYW5zbWlzc2lvbiBhbmQsIGluZGlyZWN0bHks IGFzc2lnbiAmbmJzcDszNDUyNTk4NjUgZm9yIG9yaWdpbmFsIC48bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmE9c3NyYzo8 YSBocmVmPSJ0ZWw6MjY5Mzc1NjI0OSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25lIj4yNjkzNzU2MjQ5PC9zcGFuPjwvYT4gZm10 cDo5Ng0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K bT12aWRlbyA2MjE2NCBSVFAvU0FWUEYgMTAwIDExNiAxMTcgOTY8YnI+DQphPW1pZDp2aWRlbzxi cj4NCmE9cnRwbWFwOjEwMCBWUDgvOTAwMDA8YnI+DQphPXJ0cG1hcDoxMTYgcmVkLzkwMDAwPGJy Pg0KYT1ydHBtYXA6MTE3IHVscGZlYy85MDAwMDxicj4NCmE9cnRwbWFwOjk2IHJ0eC85MDAwMDxi cj4NCmE9Zm10cDo5NiBhcHQ9MTAwPGJyPg0KYT1zc3JjLWdyb3VwOkZJRCAzNDUyNTk4NjUgPGEg aHJlZj0idGVsOjI2OTM3NTYyNDkiIHRhcmdldD0iX2JsYW5rIj4yNjkzNzU2MjQ5PC9hPjxicj4N CmE9c3NyYzozNDUyNTk4NjUgY25hbWU6ZXJTN0UvS0hMWUtUZWpOczxicj4NCmE9c3NyYzozNDUy NTk4NjUgbXNpZDpEV3BXY3Q5YldLelRNTllabjViS1Znd1o4TWZ5MkV0ZnFCWTU8YnI+DQpjMDEz NGYwNS1lN2MyLTRhZmQtYTk3OS00ZTIyNGRlNWViOTE8YnI+DQphPXNzcmM6MzQ1MjU5ODY1IG1z bGFiZWw6RFdwV2N0OWJXS3pUTU5ZWm41YktWZ3daOE1meTJFdGZxQlk1PGJyPg0KYT1zc3JjOjM0 NTI1OTg2NSBsYWJlbDpjMDEzNGYwNS1lN2MyLTRhZmQtYTk3OS00ZTIyNGRlNWViOTE8YnI+DQph PXNzcmM6PGEgaHJlZj0idGVsOjI2OTM3NTYyNDkiIHRhcmdldD0iX2JsYW5rIj4yNjkzNzU2MjQ5 PC9hPiBjbmFtZTplclM3RS9LSExZS1Rlak5zPGJyPg0KYT1zc3JjOjxhIGhyZWY9InRlbDoyNjkz NzU2MjQ5IiB0YXJnZXQ9Il9ibGFuayI+MjY5Mzc1NjI0OTwvYT4gbXNpZDpEV3BXY3Q5YldLelRN TllabjViS1Znd1o4TWZ5MkV0ZnFCWTU8YnI+DQpjMDEzNGYwNS1lN2MyLTRhZmQtYTk3OS00ZTIy NGRlNWViOTE8YnI+DQphPXNzcmM6PGEgaHJlZj0idGVsOjI2OTM3NTYyNDkiIHRhcmdldD0iX2Js YW5rIj4yNjkzNzU2MjQ5PC9hPiBtc2xhYmVsOkRXcFdjdDliV0t6VE1OWVpuNWJLVmd3WjhNZnky RXRmcUJZNTxicj4NCmE9c3NyYzo8YSBocmVmPSJ0ZWw6MjY5Mzc1NjI0OSIgdGFyZ2V0PSJfYmxh bmsiPjI2OTM3NTYyNDk8L2E+IGxhYmVsOmMwMTM0ZjA1LWU3YzItNGFmZC1hOTc5LTRlMjI0ZGU1 ZWI5MTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQo8Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gdGhlIHF1ZXN0 aW9uIG9mIHdoYXQgaWYgdGhlcmUgYXJlIDMgc3NyY3M/PG86cD48L286cD48L3NwYW4+PC9pPjwv Yj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZXIgbXkgdW5kZXJz dGFuZGluZywgdGhlcmUgaXMgb25seSBvbmUgc3NyYyBmb3Igb3JpZ2luYWwgcGF5bG9hZCBhbmQg YW5vdGhlciBmb3IgcmV0cmFuc21pc3Npb24uIFNvLCBhPXNzcmMtZ3JvdXAgY29udGFpbmluZyAz DQogc3NyY3MgaXMgcHJvYmFibHkgaW52YWxpZC48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jmx0Oy9SYWp1Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFq dTwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E5EAE2AUS70UWXCHMBA02z_-- From nobody Tue Oct 21 13:49:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB231A6F65 for ; Tue, 21 Oct 2014 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl0FfsLVKCJq for ; Tue, 21 Oct 2014 13:49:23 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04D41A1A9F for ; Tue, 21 Oct 2014 13:49:22 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id r20so3008748wiv.5 for ; Tue, 21 Oct 2014 13:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=6Ktflflc54BXEJQbLCXhOCizQkSfgETKYeG5QfeRick=; b=irbedsXtqHEvXrUJHab45PyL0Wn5mYN6naGL6mKe7SssSOCiTWPJs36FwtdLzCmOtT oqkynXrPt8CwKes6ZE0pFzGtZUajZvjtBV22LCcHGpwewpGyX2rgICowugo6j82gh9PW bGn47w+pCLdDeM8KVm9iYlSeyQj2vokw8QtfBcyjin/MVh51mjF9lNf6R3wDUKvl4wmF r0iIng9ZqxxhkIopi8ZyXm7tEki+KqKfBNUyhNwDNPEha4uiToEeLn8ZIs2Sli1shpgX CPeQR4m4GDmRy2gR/7PtLglhpwOFk+FRK0L2Bil0w5tD7EX+b5TxwYYmjrdV/ZWeIGSX GNsw== X-Received: by 10.194.185.115 with SMTP id fb19mr16592506wjc.121.1413924561453; Tue, 21 Oct 2014 13:49:21 -0700 (PDT) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id bq8sm16573747wjb.6.2014.10.21.13.49.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 13:49:20 -0700 (PDT) Message-ID: <5446C6D5.5090804@gmail.com> Date: Tue, 21 Oct 2014 22:49:25 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020009030004050604010503" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/i1sJpc0hUJpkWYWe17zkRraVYrg Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 20:49:25 -0000 This is a multi-part message in MIME format. --------------020009030004050604010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 21/10/2014 22:14, Makaraju, Maridi Raju (Raju) wrote: > > I hope I can rule my SDP logic based on standards rather than on how > Chrome implements some features. > > My question was generic: if I receive the above SDP, how do I know > which payloads each ssrc is supposed to transport? > > *//* > > */Right. Firefox may have a different interpretation./* > > */If a=ssrc-group and retransmissions are negotiated at SDP answer, > then the order of ssrcs probably does not matter as the RTP payload > values can determine the retransmission vs. original payloads./* > > */If answerer wants to know the original ssrc for rejecting > a=ssrc-group and retransmission payload then it need to know the > original ssrc./* > > *//* > > */http://tools.ietf.org/html/rfc5576#section-6.3 defines a=ssrc with > format. In the example below,/* > > */won't having the following SDP line be sufficient to assign > 2693756249 for retransmission and, indirectly, assign > 345259865 for original ./* > > */a=ssrc:2693756249 fmtp:96 /* > > -------------------------- > m=video 62164 RTP/SAVPF 100 116 117 96 > a=mid:video > a=rtpmap:100 VP8/90000 > a=rtpmap:116 red/90000 > a=rtpmap:117 ulpfec/90000 > a=rtpmap:96 rtx/90000 > a=fmtp:96 apt=100 > a=ssrc-group:FID 345259865 2693756249 > a=ssrc:345259865 cname:erS7E/KHLYKTejNs > a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=ssrc:2693756249 cname:erS7E/KHLYKTejNs > a=ssrc:2693756249 > msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=ssrc:2693756249 > mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=ssrc:2693756249 > label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > ------------------------------- > > */On the question of what if there are 3 ssrcs?/* > > */Per my understanding, there is only one ssrc for original payload > and another for retransmission. So, a=ssrc-group containing 3 ssrcs is > probably invalid./* > > *//* > > *//* > > Hi Raju I foresee that when we start working on FEC we will end up using a different ssrc to avoid asking retransmissions of FEC redundant data. So 3 ssrcs will be needed for each media stream. Regarding the ftmp ssrc attribute, syntactically it solves perfectly the problem (even if we have fec in its own ssrc), but I am not sure if semantically it is the intended usage, as it seems more to define format attributes for an specific ssrc an not to restrict the usage of the payload type to that ssrc. Also, I am not sure how that would play together with plan c/plan b/plan c/no plan (I have not followed that thread actively). Best regards Sergio --------------020009030004050604010503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 21/10/2014 22:14, Makaraju, Maridi Raju (Raju) wrote:

I hope I can rule my SDP logic based on standards rather than on how Chrome implements some features.

My question was generic: if I receive the above SDP, how do I know which payloads each ssrc is supposed to transport?

<Raju >

Right. Firefox may have a different interpretation.

If a=ssrc-group and retransmissions are negotiated at SDP answer, then the order of ssrcs probably does not matter as the RTP payload values can determine the retransmission vs. original payloads.

If answerer wants to know the original ssrc for rejecting a=ssrc-group and retransmission payload then it need to know the original ssrc.

 

http://tools.ietf.org/html/rfc5576#section-6.3 defines a=ssrc with format. In the example below,

won’t having the following SDP line be sufficient to assign 2693756249 for retransmission and, indirectly, assign  345259865 for original .

a=ssrc:2693756249 fmtp:96

--------------------------
m=video 62164 RTP/SAVPF 100 116 117 96
a=mid:video
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=ssrc-group:FID 345259865 2693756249
a=ssrc:345259865 cname:erS7E/KHLYKTejNs
a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249 cname:erS7E/KHLYKTejNs
a=ssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------

On the question of what if there are 3 ssrcs?

Per my understanding, there is only one ssrc for original payload and another for retransmission. So, a=ssrc-group containing 3 ssrcs is probably invalid.

 

</Raju>


Hi Raju

I foresee that when we start working on FEC we will end up using a different ssrc to avoid asking retransmissions of FEC redundant data. So 3 ssrcs will be needed for each media stream.

Regarding the ftmp ssrc attribute, syntactically it solves perfectly the problem (even if we have fec in its own ssrc), but I am not sure if semantically it is the intended usage, as it seems more to define format attributes for an specific ssrc an not to restrict the usage of the payload type to that ssrc. 

Also, I am not sure how that would play together with plan c/plan b/plan c/no plan (I have not followed that thread actively).

Best regards
Sergio
--------------020009030004050604010503-- From nobody Tue Oct 21 13:59:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F2F1A86E2 for ; Tue, 21 Oct 2014 13:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhGbjs_tRQQ4 for ; Tue, 21 Oct 2014 13:59:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0651.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::651]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EB81A86E7 for ; Tue, 21 Oct 2014 13:59:08 -0700 (PDT) Received: from CY1PR0501MB1580.namprd05.prod.outlook.com (25.161.161.154) by CY1PR0501MB1225.namprd05.prod.outlook.com (25.160.145.15) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 20:58:46 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1580.namprd05.prod.outlook.com (25.161.161.154) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 20:58:44 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.00.1054.004; Tue, 21 Oct 2014 20:58:44 +0000 From: "Wyss, Felix" To: tim panton Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYIAADzmAgAAmfQCAAFWsAIAAG4cggAEmdgCAADW+gIAAINaAgAAXDgCAAA+BgIAAIqQAgABN64CAAPELcIABF92AgATZ34CAAJFUwIABmHeAgAP3gnCAAAy6AIAAzlPg Date: Tue, 21 Oct 2014 20:58:44 +0000 Message-ID: <46b327b5be5a4fbcb508f664aea6cba2@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> <543CD1CD.3000001@alvestrand.no> <5440E38F.9070809@jesup.org> <5442B41D.6040307@jesup.org> <514191b6e7 764d30be7ea17d324d8739@CY1PR0501MB1579.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.147.12.61] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1580;UriScan:; inin-custom-wld: WL-D x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(51704005)(106356001)(106116001)(105586002)(95666004)(77096002)(21056001)(76482002)(66066001)(64706001)(99396003)(97736003)(31966008)(54356999)(99286002)(50986999)(107046002)(76176999)(120916001)(80022003)(230783001)(46102003)(86362001)(2656002)(20776003)(92566001)(4396001)(33646002)(74316001)(40100003)(110136001)(122556002)(93886004)(76576001)(85852003)(101416001)(87936001)(108616004)(85306004)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1580; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:3; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1225; X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/td00LXHBumjsJ2AwBWlu1b841wQ Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 20:59:32 -0000 > > Yes, that's the intended use-case: The middlebox is a trusted man-in-th= e- > middle. In order to record and/or perform analytics on the media flowing > through it, it obviously has to decrypt it. That can only be done by > terminating DTLS (and decrypting/re-encrypting SRTP.) >=20 > If the middle box is trusted, only interested in media and known about by > the application, then the application should create a separate direct dat= a > channel only DTLS connection between the endpoints that bypasses the > middle box, with a small amount of extra application effort we remove the > need for even more random extra SDP lines. Remember these are > programmable endpoints - not dumb SIP devices with fixed behaviours. >=20 > Unless the middle box is performing 'analytics' on the DC data too, but t= hat > isn't the use-case you mentioned. Having to use one of the endpoints to fork the media for recording and anal= ytics is not acceptable for us. Many of our customers require that all int= eractions are recorded exactly as they occur between the endpoints. Often = they are required to do that for legal or compliance reasons. It's actuall= y pretty certain that some of them will want the data streams recorded too.= =20 --Felix From nobody Tue Oct 21 15:14:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEDD1A87A9; Tue, 21 Oct 2014 15:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ3nKkQoBYin; Tue, 21 Oct 2014 15:13:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D51D1A8771; Tue, 21 Oct 2014 15:13:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021221359.1954.18762.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 15:13:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zszkHSjR4jmp0hgj2lamycz_aDE Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-18.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 22:14:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Authors : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-18.txt Pages : 44 Date : 2014-10-21 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 21 15:18:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7601A8796 for ; Tue, 21 Oct 2014 15:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBAe2tZGOfuH for ; Tue, 21 Oct 2014 15:18:52 -0700 (PDT) Received: from relay.mailchannels.net (si-002-i157.relay.mailchannels.net [108.178.49.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3E48C1A8745 for ; Tue, 21 Oct 2014 15:18:50 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id B0573278E99 for ; Tue, 21 Oct 2014 22:18:48 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.248.11.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.3.1); Tue, 21 Oct 2014 22:18:49 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1413929928942:811510354 X-MC-Ingress-Time: 1413929928942 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:64534 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XghlP-0002W7-GD for rtcweb@ietf.org; Tue, 21 Oct 2014 17:18:47 -0500 Message-ID: <5446DBB1.7090801@jesup.org> Date: Tue, 21 Oct 2014 18:18:25 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> <543CD1CD.3000001@alvestrand.no> <5440E38F.9070809@jesup.org> <5442B41D.6040307@jesup.org> <514191b6e7 764d30be7ea17d324d8739@CY1PR0501MB1579.namprd05.prod.outlook.com> <46b327b5be5a4fbcb508f664aea6cba2@CY1PR0501MB1579.namprd05.prod.outlook.com> In-Reply-To: <46b327b5be5a4fbcb508f664aea6cba2@CY1PR0501MB1579.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/POh9TpRlsqvxUQ0x7SImm6je_B4 Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 22:18:54 -0000 On 10/21/2014 4:58 PM, Wyss, Felix wrote: >>> Yes, that's the intended use-case: The middlebox is a trusted man-in-the- >> middle. In order to record and/or perform analytics on the media flowing >> through it, it obviously has to decrypt it. That can only be done by >> terminating DTLS (and decrypting/re-encrypting SRTP.) >> >> If the middle box is trusted, only interested in media and known about by >> the application, then the application should create a separate direct data >> channel only DTLS connection between the endpoints that bypasses the >> middle box, with a small amount of extra application effort we remove the >> need for even more random extra SDP lines. Remember these are >> programmable endpoints - not dumb SIP devices with fixed behaviours. >> >> Unless the middle box is performing 'analytics' on the DC data too, but that >> isn't the use-case you mentioned. > Having to use one of the endpoints to fork the media for recording and analytics is not acceptable for us. Many of our customers require that all interactions are recorded exactly as they occur between the endpoints. Often they are required to do that for legal or compliance reasons. It's actually pretty certain that some of them will want the data streams recorded too. I had a suspicion that this was the intended use-case - and it's a real use-case for certain applications/industries. So, for those applications (remembering that webrtc applications are not random external devices, but basically code linked to the usage) just either use pre-defined or external negotiation for channel assignments, or implement *in the application* allocation-choosing strategy. Such as: middlebox: offer to A and B (actpass) A: accept (active) B: accept (active) ok, now both are on the same "evenness" both statically open (pre-defined) channel 0 always Both send a random token value The side with the lower random value is even, and the other is odd All channel allocations are preceeded by message on channel 0 that amounts to an "I'm opening channel N with these params" that takes the place of DCEP Encapsulate this behavior in some simple functions that take the place of the default createDataChannel()/etc There are other solutions of course for glare resolution. If you want, if the two sides chose the opposite evenness, you just leave createDataChannel alone. There are a LOT of ways to deal with this at the application level, since the application "should" know it's talking to (or may be talking to) a middlebox that will decrypt/forward things. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Oct 21 15:19:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1E1A8745 for ; Tue, 21 Oct 2014 15:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8zi7mcHwuh6 for ; Tue, 21 Oct 2014 15:19:28 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA67B1A87C6 for ; Tue, 21 Oct 2014 15:19:28 -0700 (PDT) Received: from [130.209.254.2] (port=51799 helo=vpn2.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xghm2-0008IB-6J for rtcweb@ietf.org; Tue, 21 Oct 2014 23:19:27 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <20141021221359.1954.18762.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 18:19:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <148136AD-9C9E-4C91-B67B-370895F4D36C@csperkins.org> References: <20141021221359.1954.18762.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1VLI80lKxarRF5csi-Yghe_8JSI Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-18.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 22:19:31 -0000 This version attempts to align the terminology with the latest = rtcweb-overview draft. Aside from (hopefully) fixing the terminology, = there are no other changes. Colin On 21 Oct 2014, at 18:13, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Authors : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-18.txt > Pages : 44 > Date : 2014-10-21 >=20 > Abstract: > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-18 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-18 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins https://csperkins.org/ From nobody Wed Oct 22 03:28:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF281A902A for ; Wed, 22 Oct 2014 03:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i97NpRWJJyQZ for ; Wed, 22 Oct 2014 03:28:03 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 414041A8BAF for ; Wed, 22 Oct 2014 03:28:02 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id B535D23F0491 for ; Wed, 22 Oct 2014 12:28:01 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 12:28:01 +0200 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Agenda for the upcoming meeting Thread-Index: AQHP6lyeBv1/hIPnb0eX/BgOoxserpw78DOQ Date: Wed, 22 Oct 2014 10:28:00 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5CFC5E@MCHP04MSX.global-ad.net> References: <544118D5.2080702@alvestrand.no> 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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E5CFC5EMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1O1Ouvzyk1aRgpCaWBKPEu3-CMY Subject: Re: [rtcweb] Agenda for the upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 10:28:05 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E5CFC5EMCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIHBsZWFzZSBsZXTigJlzIHNwZW5kIHNvbWUgdGltZSBkaXNjdXNzaW5nIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTAzLg0KDQpSZWdh cmRzDQpBbmR5DQoNCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IDE3IE9jdG9iZXIgMjAxNCAy Mzo0OQ0KVG86IEhhcmFsZCBBbHZlc3RyYW5kDQpDYzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gQWdlbmRhIGZvciB0aGUgdXBjb21pbmcgbWVldGluZw0KDQpJIHdvdWxk IGxpa2UgdG8gZGlzY3VzcyBlbnRlcnByaXNlIFdlYlJUQyBwcm94aWVzLCBhIHByZXZpb3VzbHkg dW5hZGRyZXNzZWQgcmVxdWlyZW1lbnQgd2hpY2ggbm93IGhhcyBhIHByb3Bvc2FsIGluDQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybi0wMw0K DQpPbiBGcmksIE9jdCAxNywgMjAxNCBhdCA2OjI1IEFNLCBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFy YWxkQGFsdmVzdHJhbmQubm88bWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPj4gd3JvdGU6DQpP biAxMC8xNi8yMDE0IDA3OjEwIFBNLCBUZWQgSGFyZGllIHdyb3RlOg0KRHVyaW5nIHRoaXMgbW9y bmluZyBjaGFpcnMgY2FsbCwgd2UgZGlzY3Vzc2VkIHRoZSBhZ2VuZGEgZm9yIHRoZSB1cGNvbWlu ZyBtZWV0aW5nLiAgVGhlIHR3byBiaWcgaXRlbXMgYXJlIEpTRVAgYW5kIHRoZSB2aWRlbyBjb2Rl YyBkaXNjdXNzaW9uLCBhbmQgb3VyIGN1cnJlbnQgdGhvdWdodCBpcyB0byBoYXZlIHRoZSBKU0VQ IGRpc2N1c3Npb24gb24gTW9uZGF5IGFuZCB0aGUgdmlkZW8gY29kZWMgZGlzY3Vzc2lvbiBvbiBU aHVyc2RheS4gIFRoZXJlIGFyZSBhIG51bWJlciBvZiBpdGVtcyB3ZSBtYXkgbmVlZCB0byBkaXNj dXNzOyBpZiB0aGVyZSBhcmUgcGFydGljdWxhciBpc3N1ZXMgeW91IGZlZWwgd2UgbmVlZCB0byBj b3ZlciwgcGxlYXNlIHNlbmQgYSBtZXNzYWdlIHRvIHRoZSBsaXN0IHdpdGggdGhlIHRvcGljIGFu ZCB0aGUgYW1vdW50IG9mIHRpbWUgeW91IGZlZWwgeW91IG5lZWQuDQoNCldlIGhhdmUgbm90IGhh ZCBmYWNlIHRvIGZhY2UgZGlzY3Vzc2lvbiBvbiBkcmFmdC1hbHZlc3RyYW5kLXJ0Y3dlYi1nYXRl d2F5cyAoYW5kIG5vdCBtdWNoIGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCBlaXRoZXIp Lg0KDQpJJ2QgbGlrZSB0byBoYXZlIGEgcmV2aWV3IG9mIHRoYXQgZG9jdW1lbnQgb24gdGhlIGFn ZW5kYS4NCg0KTm90ZTogSW4gbXkgb3BpbmlvbiwgdGhlIGNoYWlycyBjYW4gY2hvb3NlIHRvIGRl Y2lkZSBvbiB3aGV0aGVyIHRoZSBncm91cCBzaG91bGQgYWRvcHQgdGhlIGRyYWZ0IGJlZm9yZSwg ZHVyaW5nIG9yIGFmdGVyIHRoZSBtZWV0aW5nLCB3aXRoIG9yIHdpdGhvdXQgY2FsbGluZyBmb3Ig Y29uc2Vuc3VzIG9mIHRoZSBXRy4NCg0KSSB3b3VsZCBsaWtlIHRvIGhhdmUgdGhlIGNoYWlycyBz YXkgd2hhdCB0aGV5IGludGVuZCB0byBkbyBhYm91dCB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KdGhh bmtzLA0KDQpUZWQsIEN1bGxlbiwgU2Vhbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCg0KcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxt YWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWINCg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF1E5CFC5EMCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzIHBsZWFzZSBsZXTigJlzIHNwZW5kIHNvbWUgdGlt ZSBkaXNjdXNzaW5nDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm4tMDMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTAzPC9hPi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5k eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiAxNyBPY3Rv YmVyIDIwMTQgMjM6NDk8YnI+DQo8Yj5Ubzo8L2I+IEhhcmFsZCBBbHZlc3RyYW5kPGJyPg0KPGI+ Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJd IEFnZW5kYSBmb3IgdGhlIHVwY29taW5nIG1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgZW50 ZXJwcmlzZSBXZWJSVEMgcHJveGllcywgYSBwcmV2aW91c2x5IHVuYWRkcmVzc2VkIHJlcXVpcmVt ZW50IHdoaWNoIG5vdyBoYXMgYSBwcm9wb3NhbCBpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTAzIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybi0wMzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBPY3QgMTcsIDIwMTQg YXQgNjoyNSBBTSwgSGFyYWxkIEFsdmVzdHJhbmQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRA YWx2ZXN0cmFuZC5ubyIgdGFyZ2V0PSJfYmxhbmsiPmhhcmFsZEBhbHZlc3RyYW5kLm5vPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDEwLzE2LzIwMTQgMDc6MTAgUE0sIFRlZCBIYXJkaWUgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkR1cmluZyB0aGlzIG1vcm5pbmcgY2hhaXJzIGNhbGwsIHdlIGRpc2N1c3NlZCB0aGUgYWdl bmRhIGZvciB0aGUgdXBjb21pbmcgbWVldGluZy4mbmJzcDsgVGhlIHR3byBiaWcgaXRlbXMgYXJl IEpTRVAgYW5kIHRoZSB2aWRlbyBjb2RlYyBkaXNjdXNzaW9uLCBhbmQgb3VyIGN1cnJlbnQgdGhv dWdodCBpcyB0byBoYXZlIHRoZSBKU0VQIGRpc2N1c3Npb24NCiBvbiBNb25kYXkgYW5kIHRoZSB2 aWRlbyBjb2RlYyBkaXNjdXNzaW9uIG9uIFRodXJzZGF5LiZuYnNwOyBUaGVyZSBhcmUgYSBudW1i ZXIgb2YgaXRlbXMgd2UgbWF5IG5lZWQgdG8gZGlzY3VzczsgaWYgdGhlcmUgYXJlIHBhcnRpY3Vs YXIgaXNzdWVzIHlvdSBmZWVsIHdlIG5lZWQgdG8gY292ZXIsIHBsZWFzZSBzZW5kIGEgbWVzc2Fn ZSB0byB0aGUgbGlzdCB3aXRoIHRoZSB0b3BpYyBhbmQgdGhlIGFtb3VudCBvZiB0aW1lIHlvdSBm ZWVsIHlvdSBuZWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpXZSBoYXZlIG5vdCBoYWQgZmFj ZSB0byBmYWNlIGRpc2N1c3Npb24gb24gZHJhZnQtYWx2ZXN0cmFuZC1ydGN3ZWItZ2F0ZXdheXMg KGFuZCBub3QgbXVjaCBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QgZWl0aGVyKS48YnI+ DQo8YnI+DQpJJ2QgbGlrZSB0byBoYXZlIGEgcmV2aWV3IG9mIHRoYXQgZG9jdW1lbnQgb24gdGhl IGFnZW5kYS48YnI+DQo8YnI+DQpOb3RlOiBJbiBteSBvcGluaW9uLCB0aGUgY2hhaXJzIGNhbiBj aG9vc2UgdG8gZGVjaWRlIG9uIHdoZXRoZXIgdGhlIGdyb3VwIHNob3VsZCBhZG9wdCB0aGUgZHJh ZnQgYmVmb3JlLCBkdXJpbmcgb3IgYWZ0ZXIgdGhlIG1lZXRpbmcsIHdpdGggb3Igd2l0aG91dCBj YWxsaW5nIGZvciBjb25zZW5zdXMgb2YgdGhlIFdHLjxicj4NCjxicj4NCkkgd291bGQgbGlrZSB0 byBoYXZlIHRoZSBjaGFpcnMgc2F5IHdoYXQgdGhleSBpbnRlbmQgdG8gZG8gYWJvdXQgdGhpcyBk b2N1bWVudC48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQp0aGFua3MsPGJyPg0KPGJyPg0K VGVkLCBDdWxsZW4sIFNlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ydGN3ZWIgbWFpbGluZyBsaXN0PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRj d2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF1E5CFC5EMCHP04MSXglobal_-- From nobody Wed Oct 22 05:17:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EED91A9041 for ; Wed, 22 Oct 2014 05:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojh6XuuL0h9R for ; Wed, 22 Oct 2014 05:17:29 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EA81A8F49 for ; Wed, 22 Oct 2014 05:17:28 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-8e-5447a05688e7 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 64.26.24955.650A7445; Wed, 22 Oct 2014 14:17:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 14:17:26 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Bernard Aboba , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Comments on draft-ietf-rtcweb-video Section 4.2 (H.264) Thread-Index: AQHP5zkt7lQPDj5kwUaiHjUMtDl85Q== Date: Wed, 22 Oct 2014 12:17:24 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0AA814@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW7YAvcQg95NphYb9v1ntlj7r53d gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MpoaT7EXPCIpaK3YS5zA+N75i5GTg4JAROJ eXOXskHYYhIX7q0Hsrk4hASOMkpM3fqOFcJZwiixZM0tRpAqNoFAia37FoB1iAgESbR1LQSL Cwv4SuzfdpYJIh4g0fOoH8rWk7h/5xGYzSKgKtG+9wLYZl6g+jut78HiQkD1P/Z9A7MZga74 fmoNmM0sIC5x68l8JojrBCSW7DkPdbWoxMvH/1ghbCWJHxsusUDU60ncmDqFDcLWlli28DXU LkGJkzOfsExgFJmFZOwsJC2zkLTMQtKygJFlFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg RBzc8lt1B+PlN46HGAU4GJV4eBfwu4cIsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFq UXxRaU5q8SFGJg5OqQbGuC0qsqG7zm08MuOnBP9RLQmfLMvLmjb3JkWfqjGevfjz3l2Bsw0e LF3Vanztqr7IUp8QaWYDjdyXKZqVqjsFHne72aow1ztt9Lz4eGlavKbyTNaldj9mWHX+YTC7 HXu7RXl/2vOfbC9mahV/arNe02gfNn9XamNw2Re5d4pX/ssvFO+zbctWYinOSDTUYi4qTgQA rsdY42kCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/U-9_cYuEEO53HG6LP7H-h4wo8L0 Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-video Section 4.2 (H.264) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 12:17:30 -0000 On 14/10/14 00:58, Bernard Aboba wrote:=0A= > This section needs more work. Aside from requiring support for=0A= > packetization mode 1, we could use additional text on robustness.=0A= >=0A= > Could aspects of existing H.264 robustness recommendations (such 3GPP=0A= > S4-140961, designed for Video over LTE) could be incorporated?=0A= =0A= You mean the part saying more or less:=0A= =0A= * NACK messages mean lost frames=0A= * PLI must be supported=0A= * FIR must be supported=0A= =0A= To me that would make sense. But should it go into section 4.2 or section 5= ?=0A= =0A= Stefan=0A= =0A= From nobody Wed Oct 22 07:22:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E670D1AC414; Wed, 22 Oct 2014 07:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCKURLAPrDdj; Wed, 22 Oct 2014 07:22:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B9B1AC3DC; Wed, 22 Oct 2014 07:22:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022142214.1415.77229.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 07:22:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/THVIe_MZfUb3i0eREzQPGcUTdn0 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:22:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-07.txt Pages : 15 Date : 2014-10-22 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-transports-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 22 07:44:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BFF1ACD0F for ; Wed, 22 Oct 2014 07:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9JSI1rAciap for ; Wed, 22 Oct 2014 07:44:01 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 98DA51ACD0B for ; Wed, 22 Oct 2014 07:44:01 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id A936993C1AF; Wed, 22 Oct 2014 14:43:59 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Oct 2014 16:43:59 +0200 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uCr7iIWuzcKxJV3PLa-473qHbKU Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:44:03 -0000 Section 3.4 " WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application." Should we mention which takes precedence? If configured in the browser, = start with that server. If not use the one provided by the application. Maybe we should clarify that turn DNS discovery MUST be used to provide = failover and load balancing. /O= From nobody Wed Oct 22 07:51:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD351ACD16 for ; Wed, 22 Oct 2014 07:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QY2TVXY_EIi for ; Wed, 22 Oct 2014 07:51:35 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4041ACD1C for ; Wed, 22 Oct 2014 07:51:34 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-00-5447c474f9e4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A9.AD.04387.474C7445; Wed, 22 Oct 2014 16:51:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 16:51:32 +0200 From: Christer Holmberg To: "Olle E. Johansson" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft-ietf-rtcweb-transports-07.txt Thread-Index: AQHP7galfY5nqzUVrUy4990W3b6dcJw8MfiQ Date: Wed, 22 Oct 2014 14:51:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C18C0@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW7JEfcQg5db9Cxerj7EbLH2Xzu7 A5PHtLUrWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx/8ds9oIP7BXb228zNTAeYOti5OSQEDCR WHxpFpQtJnHh3nogm4tDSOAoo8Stf2uZIJwljBJTXs4Ecjg42AQsJLr/aYM0iAj4Skw8vZod xBYWsJTY8HgZM0TcSqJx42VGkHIRASOJG7tkQMIsAqoS37+2gpXzArUeOrQQzBYSsJU4/+ge K4jNKWAncfHiXCYQmxHonu+n1oDZzALiEreezGeCuFNAYsme88wQtqjEy8f/WCFsJYm1h7ez QNTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpxcW66 kZFealFmcnFxfp5eXmrJJkZglBzc8ttqB+PB546HGAU4GJV4eBfwu4cIsSaWFVfmHmKU5mBR EuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGw9Yf+fz/fTs2XHngNbP88dWJiSUZ jy259ZaqJwYu3KOnf6rukVpw9GS1zcfVv8jNfL30eSfr/WxfqbTGrVaWzklWqxay/7x+MXnx 4yPCnw/Zx6SIfXG45Vmq87hJfeV6q/PcT6/L7OsM0ZK9/s7g/UXZr6+rJiv5Plxq675mUfmU kL/dsdfClFiKMxINtZiLihMBfpCifnMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3CPPAvv7bGvbBFTSolwGaYmyKcQ Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:51:37 -0000 Hi, The advantage of an application configuration is that it can be dynamically= provided/updated, based on location based etc - assuming the webpage provi= der has knowledge about STUN/TURN servers, of course. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. Johansso= n Sent: 22 October 2014 17:44 To: rtcweb@ietf.org Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt Section 3.4 " WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application." Should we mention which takes precedence? If configured in the browser, sta= rt with that server. If not use the one provided by the application. Maybe we should clarify that turn DNS discovery MUST be used to provide fai= lover and load balancing. /O _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Oct 22 07:53:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636B61ACD24 for ; Wed, 22 Oct 2014 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTiGWq6ZtkaL for ; Wed, 22 Oct 2014 07:52:53 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id B206D1ACD19 for ; Wed, 22 Oct 2014 07:52:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id F0A897C00CD for ; Wed, 22 Oct 2014 16:52:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMlA3Jn2pXbt for ; Wed, 22 Oct 2014 16:52:47 +0200 (CEST) Received: from [172.28.89.184] (unknown [74.125.122.49]) by mork.alvestrand.no (Postfix) with ESMTPSA id 85D837C0055 for ; Wed, 22 Oct 2014 16:52:47 +0200 (CEST) Message-ID: <5447C4BA.6070805@alvestrand.no> Date: Wed, 22 Oct 2014 16:52:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090809050209020800060208" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Bogfu4W0GiTKFY5ZI1I5uLMUt4E Subject: Re: [rtcweb] draft-ietf-rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:52:59 -0000 This is a multi-part message in MIME format. --------------090809050209020800060208 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 08/25/2014 07:36 AM, Justin Uberti wrote: > Yes, 4571 must be used for ICE connectivity checks, when using ICE-TCP.= > > However, TURN/TCP has its own framing for STUN messages. > > I would simplify your sentence to: > > If ICE-TCP connections are used, framing according to [RFC4571] MUST= > be used for all packets, unless the content has its own framing > mechanism. Checking the list for long-delayed updates.... Checking back: The change from TCP to ICE-TCP is good (this excludes TURN-TCP from this paragraph), but the exchange leaves me uncertain about the status of STUN packets on ICE-TCP connections. Do they happen at all? If they happen, should they be RFC 4571 encapsulated, or not? > > > On Fri, Aug 22, 2014 at 8:38 AM, I=F1aki Baz Castillo > wrote: > > Hi, > > draft-ietf-rtcweb-transports-06 says: > > If TCP connections are used, RTP framing according to [RFC4571] > MUST > be used, both for the RTP packets and for the DTLS packets used = to > carry data channels. > > > Not just RTP and DTLS, but also for STUN packets must be framed wit= h > RFC4571. And I do not understand why "DTLS packets used to carry da= ta > channels". In fact all the DTLS packets (also the ones for the > handshake) must be framed as per RFC 4571. > > > So I suggest to improve the above text as follows: > > If TCP connections are used, RTP framing according to [RFC4571] > MUST > be used for the STUN packets, SRTP packets, SRTCP packets and DT= LS > packets. > > > > > > > -- > I=F1aki Baz Castillo > > > > _______________________________________________ > 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 Surveillance is pervasive. Go Dark. --------------090809050209020800060208 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 08/25/2014 07:36 AM, Justin Uberti wrote:
Yes, 4571 must be used for ICE connectivity checks, when using ICE-TCP.

However, TURN/TCP has its own framing for STUN messages.

I would simplify your sentence to:

   If ICE-TCP connections are used, framing according to [RFC4571] MUST
   be used for all packets, unless the content has its own framing mechanism.

Checking the list for long-delayed updates....

Checking back: The change from TCP to ICE-TCP is good (this excludes TURN-TCP from this paragraph), but the exchange leaves me uncertain about the status of STUN packets on ICE-TCP connections.

Do they happen at all? If they happen, should they be RFC 4571 encapsulated, or not?



On Fri, Aug 22, 2014 at 8:38 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Hi,

draft-ietf-rtcweb-transports-06 says:

   If TCP connections are used, RTP framing according to [RFC4571] MUST
   be used, both for the RTP packets and for the DTLS packets used to
   carry data channels.


Not just RTP and DTLS, but also for STUN packets must be framed with
RFC4571. And I do not understand why "DTLS packets used to carry data
channels". In fact all the DTLS packets (also the ones for the
handshake) must be framed as per RFC 4571.


So I suggest to improve the above text as follows:

   If TCP connections are used, RTP framing according to [RFC4571] MUST
   be used for the STUN packets, SRTP packets, SRTCP packets and DTLS
   packets.






--
Iñaki Baz Castillo
<ibc@aliax.net>

_______________________________________________
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



-- 
Surveillance is pervasive. Go Dark.
--------------090809050209020800060208-- From nobody Wed Oct 22 07:58:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7505C1ACD12 for ; Wed, 22 Oct 2014 07:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a77cbl1uOkI for ; Wed, 22 Oct 2014 07:57:55 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4601ACD38 for ; Wed, 22 Oct 2014 07:57:54 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id m8so3010005obr.35 for ; Wed, 22 Oct 2014 07:57:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uem9lxg3XNB0MO9Bk8lMWJOkSC4EI41l5chzCy5uyfY=; b=c9ryHeJO9RHv231tdHaTvn4tD0dVQYI5xrnu8T9N1oOfi29hgCpSz5cSAGsXfbtgfr GIGx0H/S1eGbQ3pyleX3aunRG6He5uoWxNaw4OXWC+yMqRty6Dow3OWNWxPl2YfLCBZW 0gCAYq4xJnR7hRTjf9+2m5yBRvjlnOyIrkSocoJPHZI77/8VLCLW/UzqkDovyEXCtzxJ 8BZaewvrmSB+wzwARLoVtHPuIg99N3XMQxsk+48GMxC5lfeZqTJlmcMC5Z/copDmNNDh iwxGsir4s9nWRbMFq1moeqTHo1i1IKiUA49h0TPeX9TuoSRNdgftDm0LcXOfFiunMwHd JS8w== X-Gm-Message-State: ALoCoQnHOkz2F5hQpaZvEFNAghVBA0VQKLJRZNnq3pum3gDXYzVSVXGqXImlvZSjXkTPeUI30DIn X-Received: by 10.60.147.196 with SMTP id tm4mr35924110oeb.4.1413989874300; Wed, 22 Oct 2014 07:57:54 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com. [209.85.218.49]) by mx.google.com with ESMTPSA id m39sm6452501oik.22.2014.10.22.07.57.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 07:57:53 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id a3so2781785oib.8 for ; Wed, 22 Oct 2014 07:57:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.38.135 with SMTP id g7mr36563973obk.19.1413989873791; Wed, 22 Oct 2014 07:57:53 -0700 (PDT) Received: by 10.182.16.130 with HTTP; Wed, 22 Oct 2014 07:57:53 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C18C0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C18C0@ESESSMB209.ericsson.se> Date: Wed, 22 Oct 2014 10:57:53 -0400 Message-ID: From: Benjamin Schwartz To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c3302024d5ac0506042c2b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/esDHdR28ni4wRVH7gi04Q3qf-p4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:57:59 -0000 --001a11c3302024d5ac0506042c2b Content-Type: text/plain; charset=UTF-8 FYI, the purpose of the RETURN draft ( https://tools.ietf.org/html/draft-schwartz-rtcweb-return-03) is to try to specify the precise interaction and precedence when both the browser and the application provide TURN servers. (It's not as simple as "one or the other".) I haven't considered the issues related to browser-provided STUN servers, though. On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The advantage of an application configuration is that it can be > dynamically provided/updated, based on location based etc - assuming the > webpage provider has knowledge about STUN/TURN servers, of course. > > Regards, > > Christer > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. > Johansson > Sent: 22 October 2014 17:44 > To: rtcweb@ietf.org > Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt > > Section 3.4 > > " WebRTC browsers MUST support configuration of STUN and TURN servers, > both from browser configuration and from an application." > > > Should we mention which takes precedence? If configured in the browser, > start with that server. > If not use the one provided by the application. > > Maybe we should clarify that turn DNS discovery MUST be used to provide > failover and load balancing. > > /O > _______________________________________________ > 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 > --001a11c3302024d5ac0506042c2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI, the purpose of the RETURN draft (https://tools.ietf.org/= html/draft-schwartz-rtcweb-return-03) is to try to specify the precise = interaction and precedence when both the browser and the application provid= e TURN servers. =C2=A0(It's not as simple as "one or the other&quo= t;.)

I haven't considered the issues related to brow= ser-provided STUN servers, though.
On Wed, Oct 22, 2014 at 10:51 AM, Christer Hol= mberg <christer.holmberg@ericsson.com> wrote:
Hi,

The advantage of an application configuration is that it can be dynamically= provided/updated, based on location based etc - assuming the webpage provi= der has knowledge about STUN/TURN servers, of course.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Olle E. Johansson
Sent: 22 October 2014 17:44
To: rtcweb@ietf.org
Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt

Section 3.4

" WebRTC browsers MUST support configuration of STUN and TURN servers,=
=C2=A0 =C2=A0both from browser configuration and from an application."=


Should we mention which takes precedence? If configured in the browser, sta= rt with that server.
If not use the one provided by the application.

Maybe we should clarify that turn DNS discovery MUST be used to provide fai= lover and load balancing.

/O
_______________________________________________
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

--001a11c3302024d5ac0506042c2b-- From nobody Wed Oct 22 07:59:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5C61ACD38 for ; Wed, 22 Oct 2014 07:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmTiHjl4N9JX for ; Wed, 22 Oct 2014 07:58:55 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813A11ACD1E for ; Wed, 22 Oct 2014 07:58:46 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id hz20so3063733lab.39 for ; Wed, 22 Oct 2014 07:58:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lXBrJtKkxIz1eA8d/pjOGMsL2q04tLNN27Z0s3sXPvY=; b=N9DhOyTHLRWiYvMLThSOfPS90+g7Ms54xSqX4m3oLA2NkZEEDaUw+hWFb0em9UJwny djtdt3iSD7/ZlP3exuxiYlsnrxkFTXyHJzJn8a3nzIRww+nNLmxNTA+Do1YJFv2Z6e6+ O0M2EuPWy61pzZMkvfZFfmR4VD8aWAQkN1DcRSnyr/wSYNaOZkxmhchIh4AUX8b83OCb qFU3jgeEbPA/dCSwftKuBEuPg5ZyZJ0Qi6l5GpLF0Z+TE0Z5BKWsNqhdOCLGBZBQWCUM O1JRqpA28XATM4tzCz3TuX3Oa2/bJWLPIZjRbLSYgykoiFsNql2wfiJ8fb8wCeQ4XMV8 eeYA== X-Gm-Message-State: ALoCoQn4RXE6kGejMcMXtCKo/ylnG9lbzcua5ftqJhyEtvY6GnNveqJV/MwvQjOFy9ojxsKtxF0N MIME-Version: 1.0 X-Received: by 10.112.54.162 with SMTP id k2mr41999951lbp.63.1413989924851; Wed, 22 Oct 2014 07:58:44 -0700 (PDT) Received: by 10.25.137.9 with HTTP; Wed, 22 Oct 2014 07:58:44 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C18C0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C18C0@ESESSMB209.ericsson.se> Date: Wed, 22 Oct 2014 08:58:44 -0600 Message-ID: From: Simon Perreault To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c3eeee2feffe0506042fae Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5eMIYXpqWAeGPjVIifSV0n5giWU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:59:02 -0000 --001a11c3eeee2feffe0506042fae Content-Type: text/plain; charset=UTF-8 I just want to mention this: http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00 I think that both browser and application configuration are included in step #1 of the discovery algorithm, so that doesn't answer Olle's question. But we still need to keep the whole discovery process in mind. Simon On Wed, Oct 22, 2014 at 8:51 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The advantage of an application configuration is that it can be > dynamically provided/updated, based on location based etc - assuming the > webpage provider has knowledge about STUN/TURN servers, of course. > > Regards, > > Christer > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. > Johansson > Sent: 22 October 2014 17:44 > To: rtcweb@ietf.org > Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt > > Section 3.4 > > " WebRTC browsers MUST support configuration of STUN and TURN servers, > both from browser configuration and from an application." > > > Should we mention which takes precedence? If configured in the browser, > start with that server. > If not use the one provided by the application. > > Maybe we should clarify that turn DNS discovery MUST be used to provide > failover and load balancing. > > /O > _______________________________________________ > 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 > --001a11c3eeee2feffe0506042fae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just want to mention this:

http:= //tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00

I think that both browser and application configuratio= n are included in step #1 of the discovery algorithm, so that doesn't a= nswer Olle's question. But we still need to keep the whole discovery pr= ocess in mind.

Simon

On Wed, Oct 22, 2014 at 8:51 AM, Ch= rister Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

The advantage of an application configuration is that it can be dynamically= provided/updated, based on location based etc - assuming the webpage provi= der has knowledge about STUN/TURN servers, of course.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Olle E. Johansson
Sent: 22 October 2014 17:44
To: rtcweb@ietf.org
Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt

Section 3.4

" WebRTC browsers MUST support configuration of STUN and TURN servers,=
=C2=A0 =C2=A0both from browser configuration and from an application."=


Should we mention which takes precedence? If configured in the browser, sta= rt with that server.
If not use the one provided by the application.

Maybe we should clarify that turn DNS discovery MUST be used to provide fai= lover and load balancing.

/O
_______________________________________________
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

--001a11c3eeee2feffe0506042fae-- From nobody Wed Oct 22 08:30:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91C81ACD6B for ; Wed, 22 Oct 2014 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDvgc4wbUgby for ; Wed, 22 Oct 2014 08:30:20 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA551ACD5C for ; Wed, 22 Oct 2014 08:30:17 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id x12so526774qac.7 for ; Wed, 22 Oct 2014 08:30:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=gdBhcw5rgUtnVuPWuPyAQgST/y3ogEuAJm8R1rKX35g=; b=drN6OEZBdBbBPjhmk/rPLi11aYs9VWFZRfB34Hz/WEtHOOouelkDyeT1VSns8ucPhP DD+ropbtAE+PZqadoR1ksm/3z34KIB0XeHzPKaB5mfoqEl+m8kjj0TQIIX/9h40oit2+ huVcF5R+y2504My7JNC5AZjKwXVzp8eZ8CRK5ssWt19U2Wp/wi+AhM8cIaq70xZ6gy5h +NdE8Nqpw9YBx3ZrWDmGF2Vy5U37AhAmbchnmAgTKwpLrR2/eLnlFGoSUP6zNELGYVm9 b33Ji2gARgKHYhG1ZxFWJKMWP4GBHK7rbnmAbPOcwGNM/a5YZbVb9k+q0SW4qmLk85No u0Yg== X-Gm-Message-State: ALoCoQmhE1DiF9mBBwn/ielc2q7ItnO19bp5nn0XNT/h9ZEEZzjWxRlklaC5KzLU3Ak/y+nIbFx3 X-Received: by 10.140.84.106 with SMTP id k97mr53717816qgd.76.1413991816155; Wed, 22 Oct 2014 08:30:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 22 Oct 2014 08:29:54 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 22 Oct 2014 17:29:54 +0200 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F9_JeBGEDjVnWkDslVMn1cPcJP4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 15:30:26 -0000 2014-10-21 22:02 GMT+02:00 Justin Uberti : > In all seriousness, it would be nice if this behavior was standardized, s= o > that applications could have deterministic behavior. If we can come up wi= th > appropriate text about the ordering of SSRCs, this could be written into > JSEP's handling of setLocalDescription. So I expect a new draft about how to map ssrc values and payload-types in SDP. I think we already have 4 or 5 drafts about mapping or grouping stuff in SDP, but it looks like having them is not enough to define which payload-types are carried over each declared SSRC within a transport or m line (or bundled m lines within the same transport because what a m line represents is no longer clear). Is that? do we need a new SDP draft? or is it enough if we create a convention within the WebRTC context? Regards. --=20 I=C3=B1aki Baz Castillo From nobody Wed Oct 22 09:06:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4D01ACDD3 for ; Wed, 22 Oct 2014 09:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOVAw4Djk1HK for ; Wed, 22 Oct 2014 09:06:25 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7471ACDCC for ; Wed, 22 Oct 2014 09:06:25 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id C13C3B3766B7E; Wed, 22 Oct 2014 16:06:21 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9MG68oJ014329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 12:06:23 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 12:06:23 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Sergio Garcia Murillo , "rtcweb@ietf.org" Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw7JCgA///BDVCAAGQngIAA/6NQ Date: Wed, 22 Oct 2014 16:06:22 +0000 Message-ID: References: <5446C6D5.5090804@gmail.com> In-Reply-To: <5446C6D5.5090804@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5EC0CAUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EJPCYbFrJ5WV0oQt7tEzCqYQ8Lc Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 16:06:29 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5EC0CAUS70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sergio, On 21/10/2014 22:14, Makaraju, Maridi Raju (Raju) wrote: I hope I can rule my SDP logic based on standards rather than on how Chrome= implements some features. My question was generic: if I receive the above SDP, how do I know which pa= yloads each ssrc is supposed to transport? Right. Firefox may have a different interpretation. If a=3Dssrc-group and retransmissions are negotiated at SDP answer, then th= e order of ssrcs probably does not matter as the RTP payload values can det= ermine the retransmission vs. original payloads. If answerer wants to know the original ssrc for rejecting a=3Dssrc-group an= d retransmission payload then it need to know the original ssrc. http://tools.ietf.org/html/rfc5576#section-6.3 defines a=3Dssrc with format= . In the example below, won't having the following SDP line be sufficient to assign 2693756249 for retransmission and, indirectly, assign 345259865 for origi= nal . a=3Dssrc:2693756249 fmtp:96 -------------------------- m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 a=3Dmid:video a=3Drtpmap:100 VP8/90000 a=3Drtpmap:116 red/90000 a=3Drtpmap:117 ulpfec/90000 a=3Drtpmap:96 rtx/90000 a=3Dfmtp:96 apt=3D100 a=3Dssrc-group:FID 345259865 2693756249 a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 c0134f05-e7c2-4afd-a979-4e224de5eb91 a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqB= Y5 c0134f05-e7c2-4afd-a979-4e224de5eb91 a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2Et= fqBY5 a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5e= b91 ------------------------------- On the question of what if there are 3 ssrcs? Per my understanding, there is only one ssrc for original payload and anoth= er for retransmission. So, a=3Dssrc-group containing 3 ssrcs is probably in= valid. Hi Raju I foresee that when we start working on FEC we will end up using a differen= t ssrc to avoid asking retransmissions of FEC redundant data. So 3 ssrcs wi= ll be needed for each media stream. But for FEC, you will have to specify a different a=3Dssrc-group:FID. So, I= think a=3Dssrc-group:FID will still have 2 ssrcs only. Regarding the ftmp ssrc attribute, syntactically it solves perfectly the pr= oblem (even if we have fec in its own ssrc), but I am not sure if semantica= lly it is the intended usage, as it seems more to define format attributes = for an specific ssrc an not to restrict the usage of the payload type to th= at ssrc. Whatever was the initial intended purpose, I think it can be put to use it = for this (new) usage. By definition, retransmission payload can only be sen= t on one ssrc only and also the original payloads can only be sent on one s= src only. So, assuming there is only one retransmission payload independent= of # of original payloads, just associating it to an ssrc unambiguously m= aps both ssrcs. But still, an explicit mapping for all ssrcs can also be do= ne, thought which is unnecessary I think. BR Raju Also, I am not sure how that would play together with plan c/plan b/plan c/= no plan (I have not followed that thread actively). Best regards Sergio --_000_E1FE4C082A89A246A11D7F32A95A17828E5EC0CAUS70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sergio,

 <= /p>


On 21/10/2014 22:14, Makaraju, Maridi Raju (Raju) wrote:

I hope I can rule my SDP logic based on standards rather than on how Chr= ome implements some features.

My question was generic: if I receive the above SDP, how do I know which= payloads each ssrc is supposed to transport?

<Raju >

Right. Firefox may have a different interpretation.=

If a=3Dssrc-group and retransmissions are negotiated at SDP answer, the= n the order of ssrcs probably does not matter as the RTP payload values can determine the retransmission vs. original payloads.<= /b>

If answerer wants to know the original ssrc for rejecting a=3Dssrc-grou= p and retransmission payload then it need to know the original ssrc.

 

http://tools= .ietf.org/html/rfc5576#section-6.3 defines a=3Dssrc with format. In the example below,

won’t having the following SDP line be sufficient to assign 2693756249 for retransmission and, indirect= ly, assign  345259865 for original .

a=3Dssrc:2693756249 fmtp:96

-------------------------- m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2= 693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 l= abel:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:= erS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:D= WpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabe= l:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------

On the question of what if there are 3 ssr= cs?

Per my understanding, there is only one ssrc for original payload and a= nother for retransmission. So, a=3Dssrc-group containing 3 ssrcs is probably invalid.

 

</Raju>

 

Hi Raju

I foresee that when we start working on FEC we will end up using a differen= t ssrc to avoid asking retransmissions of FEC redundant data. So 3 ssrcs wi= ll be needed for each media stream.
<Raju2>

But for FEC, you wi= ll have to specify a different a=3Dssrc-group:FID. So, I think a=3Dssrc-gro= up:FID will still have 2 ssrcs only.

</Raju2>=


Regarding the ftmp ssrc attribute, syntactically it solves perfectly the pr= oblem (even if we have fec in its own ssrc), but I am not sure if semantica= lly it is the intended usage, as it seems more to define format attributes = for an specific ssrc an not to restrict the usage of the payload type to that ssrc. 
<Raju2>

Whatever was the in= itial intended purpose, I think it can be put to use it for this (new) usag= e. By definition, retransmission payload can only be sent on one ssrc only and also the original payloads can only be sent on one ss= rc only. So, assuming there is only one retransmission payload independent = of  # of original payloads, just associating it to an ssrc unambiguous= ly maps both ssrcs. But still, an explicit mapping for all ssrcs can also be done, thought which is unnecessary I thi= nk.

</Raju2>=

 

BR

Raju


Also, I am not sure how that would play together with plan c/plan b/plan c/= no plan (I have not followed that thread actively).

Best regards
Sergio

--_000_E1FE4C082A89A246A11D7F32A95A17828E5EC0CAUS70UWXCHMBA02z_-- From nobody Wed Oct 22 09:13:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061E31ACDBB for ; Wed, 22 Oct 2014 09:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUrLSwrXlzmX for ; Wed, 22 Oct 2014 09:13:26 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E588A1ACD82 for ; Wed, 22 Oct 2014 09:13:25 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id r20so1709752wiv.2 for ; Wed, 22 Oct 2014 09:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=GinOd/rauzJI8CtCpb+sznJNGrtVvrdDaSk6nDAEipA=; b=v7HXaNMwEfW0wyjNFNpWhrdLt7IzQo5BxdRzj65HIABN5xUyDIw6V74cueL1ZH+/ai xVRJJ8EuxuPkyIdptC5pDvgcd8pyX9jczO5jm5z8YalVKGx0YQPKZrMAYM8CkFAGRqyX CrqYea7BUs8MWOYVqaXbADeBTurGMybqA4Kq2utmi0mrKER0u0JWBBkN/qqdO4yiOGyU HcUm9lbc0GSOPi+CKUIHy6Emu2BmoyuIh7TWDXFDU4E4OWUu7r5yCh3Y7BhtfvyMqxav YoOgomV0vAdsPgJArZyZB+SPPXCWvsd2bmUuDrl8sNxlLzlQEH4RYx/VZMU6SK4A+wmp bfZg== X-Received: by 10.180.21.241 with SMTP id y17mr6833917wie.57.1413994404495; Wed, 22 Oct 2014 09:13:24 -0700 (PDT) Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id fv2sm2433469wib.2.2014.10.22.09.13.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 09:13:23 -0700 (PDT) Message-ID: <5447D7A0.8020305@gmail.com> Date: Wed, 22 Oct 2014 18:13:20 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "rtcweb@ietf.org" References: <5446C6D5.5090804@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040506050002070307010906" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bc1UAeq1vugdAn8j-tBNo7AexQc Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 16:13:28 -0000 This is a multi-part message in MIME format. --------------040506050002070307010906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 22/10/2014 18:06, Makaraju, Maridi Raju (Raju) wrote: > > Hi Raju > > I foresee that when we start working on FEC we will end up using a > different ssrc to avoid asking retransmissions of FEC redundant data. > So 3 ssrcs will be needed for each media stream. > */ /* > > */But for FEC, you will have to specify a different a=ssrc-group:FID. > So, I think a=ssrc-group:FID will still have 2 ssrcs only./* > > *//* > Indeed, in fact I was proposing in another thread to use a the ssrc-group:FEC (and remove the RED altogether). > Regarding the ftmp ssrc attribute, syntactically it solves perfectly > the problem (even if we have fec in its own ssrc), but I am not sure > if semantically it is the intended usage, as it seems more to define > format attributes for an specific ssrc an not to restrict the usage of > the payload type to that ssrc. > *//* > > */Whatever was the initial intended purpose, I think it can be put to > use it for this (new) usage. By definition, retransmission payload can > only be sent on one ssrc only and also the original payloads can only > be sent on one ssrc only. So, assuming there is only one > retransmission payload independent of # of original payloads, just > associating it to an ssrc unambiguously maps both ssrcs. But still, an > explicit mapping for all ssrcs can also be done, thought which is > unnecessary I think. /* > > *//* > I am also fine, just not sure if everyone else would agree. Best regards Sergio --------------040506050002070307010906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/10/2014 18:06, Makaraju, Maridi Raju (Raju) wrote:

Hi Raju

I foresee that when we start working on FEC we will end up using a different ssrc to avoid asking retransmissions of FEC redundant data. So 3 ssrcs will be needed for each media stream.
<Raju2>

But for FEC, you will have to specify a different a=ssrc-group:FID. So, I think a=ssrc-group:FID will still have 2 ssrcs only.

</Raju2>

Indeed, in fact I was proposing in another thread to use a the ssrc-group:FEC (and remove the RED altogether).

Regarding the ftmp ssrc attribute, syntactically it solves perfectly the problem (even if we have fec in its own ssrc), but I am not sure if semantically it is the intended usage, as it seems more to define format attributes for an specific ssrc an not to restrict the usage of the payload type to that ssrc. 
<Raju2>

Whatever was the initial intended purpose, I think it can be put to use it for this (new) usage. By definition, retransmission payload can only be sent on one ssrc only and also the original payloads can only be sent on one ssrc only. So, assuming there is only one retransmission payload independent of  # of original payloads, just associating it to an ssrc unambiguously maps both ssrcs. But still, an explicit mapping for all ssrcs can also be done, thought which is unnecessary I think.

</Raju2>

I am also fine, just not sure if everyone else would agree.

Best regards
Sergio


--------------040506050002070307010906-- From nobody Wed Oct 22 09:20:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099BE1ACE04 for ; Wed, 22 Oct 2014 09:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtORVKOlgJ0Y for ; Wed, 22 Oct 2014 09:20:10 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B64B1ACDE6 for ; Wed, 22 Oct 2014 09:20:06 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 87C51B5E20DB1; Wed, 22 Oct 2014 16:20:02 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9MGK58K009733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 12:20:05 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 12:20:05 -0400 From: "Makaraju, Maridi Raju (Raju)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Justin Uberti Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP7g0HdeZEO6Q8ck+bZW3ftl2D4pw8SgYg Date: Wed, 22 Oct 2014 16:20:05 +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: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ygCLZnp7dHuPRbzT617guQqf4eQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 16:20:12 -0000 PiAyMDE0LTEwLTIxIDIyOjAyIEdNVCswMjowMCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2ds ZS5jb20+Og0KPiA+IEluIGFsbCBzZXJpb3VzbmVzcywgaXQgd291bGQgYmUgbmljZSBpZiB0aGlz IGJlaGF2aW9yIHdhcyBzdGFuZGFyZGl6ZWQsIHNvDQo+ID4gdGhhdCBhcHBsaWNhdGlvbnMgY291 bGQgaGF2ZSBkZXRlcm1pbmlzdGljIGJlaGF2aW9yLiBJZiB3ZSBjYW4gY29tZSB1cA0KPiB3aXRo DQo+ID4gYXBwcm9wcmlhdGUgdGV4dCBhYm91dCB0aGUgb3JkZXJpbmcgb2YgU1NSQ3MsIHRoaXMg Y291bGQgYmUgd3JpdHRlbiBpbnRvDQo+ID4gSlNFUCdzIGhhbmRsaW5nIG9mIHNldExvY2FsRGVz Y3JpcHRpb24uDQo+IA0KPiBTbyBJIGV4cGVjdCBhIG5ldyBkcmFmdCBhYm91dCBob3cgdG8gbWFw IHNzcmMgdmFsdWVzIGFuZCBwYXlsb2FkLXR5cGVzDQo+IGluIFNEUC4gSSB0aGluayB3ZSBhbHJl YWR5IGhhdmUgNCBvciA1IGRyYWZ0cyBhYm91dCBtYXBwaW5nIG9yDQoNCjxSYWp1Pg0KRG8gd2Ug cmVhbGx5IG5lZWQgYSBuZXcgZHJhZnQ/IG9yIFdvbid0IHRoZSBtZWNoYW5pc20gKGE9c3NyYzo8 c3NyYz4gZm10OjxwYXlsb2FkPikgbWVudGlvbmVkIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzU1NzYjc2VjdGlvbi02LjMgYmUgc3VmZmljaWVudCBmb3IgdGhpcz8gKHdoaWNoIGlz IGJlaW5nIGRpc2N1c3NlZCBpbiB0aGlzIHNhbWUgdGhyZWFkKQkNCjwvUmFqdT4NCg0KQlINClJh anUNCg== From nobody Wed Oct 22 12:02:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFE01AD00C for ; Wed, 22 Oct 2014 12:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls_3QmExN6ud for ; Wed, 22 Oct 2014 12:01:58 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC6A1AD036 for ; Wed, 22 Oct 2014 12:01:41 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj1so4286147pad.29 for ; Wed, 22 Oct 2014 12:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z4E3UmtANYs3BLyW3kZkaPFVG232UcXRVJycDeMabC4=; b=qK/gqkTeCZnMXucpSBJRinsItkgDof3VtNFCsnOze2+gmbdDxgk4Su/jLuGiaubudd 2gmnxf4b4uukLknufF/KRVLOzGiNZIFRegVnx+1FD419PmhBPyF696J62eN+FhStETBG jrZ+lSZRnv2woAvz+xczhqd5YwtvABtUL8D6LN7VnqkXmb1sS33+ZvDt7wmaPVCXym4N cLAbEAt9xt0K/vPj7ixngB9gDeARdAhxVr4bty0a80l3h7//BuZ+dBWA/VB9S7/IbuBd NpFLn6aXZ5latDU2gRodByIB4t4+XpuCIV6jADvuXw75z9PePs1dCi4XiSDswFSTUzjW 6R3A== X-Received: by 10.70.39.35 with SMTP id m3mr60426pdk.70.1414004500267; Wed, 22 Oct 2014 12:01:40 -0700 (PDT) Received: from [192.168.1.113] (71-94-170-52.dhcp.knwc.wa.charter.com. [71.94.170.52]) by mx.google.com with ESMTPSA id s9sm14953942pdp.1.2014.10.22.12.01.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 12:01:38 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-10A6CC59-955F-4D31-94E8-2D7F50F9C270 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12B410) In-Reply-To: Date: Wed, 22 Oct 2014 12:01:37 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> References: To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5XqfBd4KeCJlH8ZeROyf0YlGciY Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 19:02:01 -0000 --Apple-Mail-10A6CC59-955F-4D31-94E8-2D7F50F9C270 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable SDP specifies payload types for RED/ULPFEC/RTX so as to allow differentiatio= n within an ssrc-group. So while an fmtp: attribute could be used to denote a= media stream on an a:ssrc line, it is not necessary. RFC 5176 Example 3 gives an example with two cameras in which there are two s= src-group lines (one for each camera), with payload type used to differentia= te between H.264 and RTX in each ssrc-group: m=3Dvideo 49174 RTP/AVPF 96 98=20 a=3Drtpmap:96 H.264/90000=20 a=3Drtpmap:98 rtx/90000=20 a=3Dfmtp:98 apt=3D96;rtx-time=3D3000=20 a=3Dssrc-group:FID 11111 22222=20 a=3Dssrc:11111 cname:user3@example.com=20 a=3Dssrc:22222 cname:user3@example.com=20 a=3Dssrc-group:FID 33333 44444=20 a=3Dssrc:33333 cname:user3@example.com=20 a=3Dssrc:44444 cname:user3@example.com I believe that RFC 5176 includes the two groups to make clear that there are= two sources so that the Answerer might choose to reject the m-line if it ca= nnot handle that. =46rom RFC 5176 Section 8: When used with the SDP Offer/Answer Model [RFC3264], SDP source-specific att= ributes describe only the sources that each party is willing to send (whethe= r it is sending RTP data or RTCP report blocks). No mechanism is provided by= which an answer can accept or reject individual sources within a media stre= am; if the set of sources in a media stream is unacceptable, the answerer's o= nly option is to reject the media stream or the entire multimedia session. Note that in the example in RFC 4588 Section 8.8 where there is only one sou= rce, there are no ssrc-group lines at all: v=3D0=20 o=3Dmascha 2980675221 2980675778 IN IP4 host.example.net=20 c=3DIN IP4 192.0.2.0=20 m=3Dvideo 49170 RTP/AVPF 96 97=20 a=3Drtpmap:96 MP4V-ES/90000=20 a=3Drtcp-fb:96 nack=20 a=3Dfmtp:96 profile-level-id=3D8;config=3D01010000012000884006682C2090A21F=20= a=3Drtpmap:97 rtx/90000=20 a=3Dfmtp:97 apt=3D96;rtx-time=3D3000 The situation would be the same for FEC groups created via ssrc-group:FEC. =46rom= =20 https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux : The FEC and the payload MAY also be multiplexed by SSRC into one single RTP s= ession, with separate SSRC values, if the association between FEC and payloa= d streams are communicated to all members of the session. If SDP is used, th= is association MAY be communicated through the FEC ssrc-group semantic [RFC5= 576]; other mechanisms are also possible. Receivers MUST NOT attempt to inte= rpret FEC streams for which they do not have information to associate them w= ith the corresponding payload streams. > On Oct 21, 2014, at 11:36 AM, I=C3=B1aki Baz Castillo wrot= e: >=20 > I hope I can rule my SDP logic based on standards rather than on how Chrom= e implements some features. >=20 > My question was generic: if I receive the above SDP, how do I know which p= ayloads each ssrc is supposed to transport? >=20 >> On 21 Oct 2014 19:57, "Peter Thatcher" wrote: >> I'm not sure where it's specified, but here's where it's implemented: >>=20 >> https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/we= brtcvideoengine.cc#4108 >>=20 >> It only supports 2 SSRCs for a FID group. It would ignore any more than t= hat. >>=20 >>> On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo wrote: >>> How is that? Where is that specified? What about if I include 3 ssrc val= ues in the ssrc-group? What is each one for? >>>=20 >>>> On 21 Oct 2014 19:31, "Peter Thatcher" wrote: >>>> 345259865 is "real" >>>> 2693756249 is rtx >>>>=20 >>>>> On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo wrote: >>>>> Hi, >>>>>=20 >>>>> May I know which SSRC (345259865 or 2693756249) will be used for the >>>>> real media stream (plus RED and FEC) and which SSRC will be used for >>>>> RTX? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------------------------- >>>>> m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 >>>>> a=3Dmid:video >>>>> a=3Drtpmap:100 VP8/90000 >>>>> a=3Drtpmap:116 red/90000 >>>>> a=3Drtpmap:117 ulpfec/90000 >>>>> a=3Drtpmap:96 rtx/90000 >>>>> a=3Dfmtp:96 apt=3D100 >>>>> a=3Dssrc-group:FID 345259865 2693756249 >>>>> a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs >>>>> a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>> a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>> a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>> a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs >>>>> a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>> a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>> a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>> ------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> RFC 5576 does not clarify it at all: >>>>>=20 >>>>> http://tools.ietf.org/html/rfc5576#section-4.2 >>>>>=20 >>>>> -------------------------------------------------- >>>>> 4.2. The "ssrc-group" Media Attribute >>>>>=20 >>>>> a=3Dssrc-group: ... >>>>>=20 >>>>> [..] >>>>>=20 >>>>> The parameter is taken from the specification of the >>>>> "group" attribute [RFC3388]. The initial semantic values defined f= or >>>>> the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] >>>>> and FEC (Forward Error Correction) [RFC4756]. In each case, the >>>>> relationship among the grouped sources is the same as the >>>>> relationship among corresponding sources in media streams grouped >>>>> using the SDP "group" attribute. >>>>> -------------------------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The referenced RFC 3388 neither clarifies it: >>>>>=20 >>>>> --------------------------------------------------- >>>>> 7.4 FID Semantics >>>>>=20 >>>>> Several "m" lines grouped together using FID semantics form a media= >>>>> flow. A media agent handling a media flow that comprises several "= m" >>>>> lines MUST send a copy of the media to every "m" line part of the >>>>> flow as long as the codecs and the direction attribute present in a= >>>>> particular "m" line allow it. >>>>>=20 >>>>> It is assumed that the application uses only one codec at a time to= >>>>> encode the media produced. This codec MAY change dynamically durin= g >>>>> the session, but at any particular moment only one codec is in use.= >>>>>=20 >>>>> The application encodes the media using the current codec and check= s >>>>> one by one all the "m" lines that are part of the flow. If a >>>>> particular "m" line contains the codec being used and the direction= >>>>> attribute is "sendonly" or "sendrecv", a copy of the encoded media i= s >>>>> sent to the address/port specified in that particular media stream.= >>>>> If either the "m" line does not contain the codec being used or the= >>>>> direction attribute is neither "sendonly" nor "sendrecv", nothing i= s >>>>> sent over this media stream. >>>>> ---------------------------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> So, how is the usage of ssrc-group? Where is it really defined? >>>>>=20 >>>>> Can I put more than 2 ssrc together in the same ssrc-group line? >>>>>=20 >>>>> How should the receiver interpret it? >>>>>=20 >>>>> Does a ssrc-group always mean RTX usage? Where is that specified in >>>>> the above SDP? >>>>>=20 >>>>> Does not the above SDP look a complete mixture of hacks and workaround= s? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> I=C3=B1aki Baz Castillo >>>>> >>>>>=20 >>>>> _______________________________________________ >>>>> 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 --Apple-Mail-10A6CC59-955F-4D31-94E8-2D7F50F9C270 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
SDP specifies payload types for RED/UL= PFEC/RTX so as to allow differentiation within an ssrc-group. So while an fm= tp: attribute could be used to denote a media stream on an a:ssrc line, it i= s not necessary.

RFC 5176 Example 3 gives an exampl= e with two cameras in which there are two ssrc-group lines (one for each cam= era), with payload type used to differentiate between H.264 and RTX in each s= src-group:


   m=3Dvideo 49174 RTP/AVPF 96 98 
 a=3Drtpmap:96 H.264/90000&=
nbsp;
 a=3Drtpmap:98 rtx/90000 
 a=3Dfmtp:98 apt=3D96;r=
tx-time=3D3000 
 a=3Dssrc-group:FID 11111 22222 
 =
;a=3Dssrc:11111 cname:user3@example.com&n=
bsp;
 a=3Dssrc:22222 cname:user3@exa=
mple.com 
 a=3Dssrc-group:FID 33333 44444 
 =
a=3Dssrc:33333 cname:user3@example.com&nb=
sp;
 a=3Dssrc:44444 cname:user3@exam=
ple.com

I believe that RFC 5176 includes the two groups to make clear that th=
ere are two sources so that the Answerer might choose to reject the m-line i=
f it cannot handle that. =46rom RFC 5176 Section 8:

<=
span style=3D"white-space: normal; background-color: rgba(255, 255, 255, 0);=
 font-family: UICTFontTextStyleBody;">When used with the SDP Offer/Answer Mo=
del [RFC3264], S=
DP source-specific attributes describe only the sources that each party is
   willing to send (whether it is sending RTP data or RTCP report
   blocks).  No mechanism is provided by which an answer can accept or
   reject individual sources within a media stream; if the set of
   sources in a media stream is unacceptable, the answerer's only option
   is to reject the media stream or the entire multimedia session.

<=
/font>
Note t=
hat in the example in RFC 4588 Section 8.8 where there is only one source, t=
here are no ssrc-group lines at all:

 v=3D0 
 o=3Dmascha 2980675221 298=
0675778 IN IP4 host.example.net =
;
&n=
bsp;c=3DIN IP4 192.0.2.0 
 m=3Dvideo 49170 RTP/AVPF 96 97 
 a=3Drt=
pmap:96 MP4V-ES/90000 
 a=3Drtcp-fb:96 nack 
 a=3Dfmtp:96 profile-=
level-id=3D8;config=3D01010000012000884006682C2090A21F 
 a=3Drtpmap:97=
 rtx/90000 
 a=3Dfmtp:97 apt=3D96;rtx-time=3D3000

The situation would be the same for FEC groups created via= ssrc-group:FEC. From 

      The FEC and the payload MA=
Y also be multiplexed by SSRC into one
      single RTP session, with separate SSRC values, if the association
      between FEC and payload streams are communicated to all members of
      the session.  If SDP is used, this association MAY be communicated
      through the FEC ssrc-group semantic [RFC5576]; other mechanisms
      are also possible.  Receivers MUST NOT attempt to interpret FEC
      streams for which they do not have information to associate them
      with the corresponding payload streams.



On Oct 21, 2014, a= t 11:36 AM, I=C3=B1aki Baz Castillo <ibc= @aliax.net> wrote:

I hope I can rule my SDP logic based on standards rather than on ho= w Chrome implements some features.

My question was generic: if I receive the above SDP, how do I= know which payloads each ssrc is supposed to transport?

On 21 Oct 2014 19:57, "Peter Thatcher" <pthatcher@google.com> wrote:
I'm not sur= e where it's specified, but here's where it's implemented:

<= div class=3D"gmail_default">https://code.google.com/p/web= rtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengine.cc#4108

It only supports 2 SSRCs for a FID group.  It wou= ld ignore any more than that.
<= br>
On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki B= az Castillo <ibc@aliax.net> wrote:
How is that? Where is that specified? What about if I inclu= de 3 ssrc values in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher" <pthatcher@google.com= > wrote:
345259865 is "real"
2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, I= =C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.  The "ssrc-group" Media Attribute

   a=3Dssrc-group:<semantics> <ssrc-id> ...

   [..]

   The <semantics> parameter is taken from the specification= of the
   "group" attribute [RFC3388].  The initial semantic values d= efined for
   the "ssrc-group" attribute are FID (Flow Identification) [RFC33= 88]
   and FEC (Forward Error Correction) [RFC4756].  In each cas= e, the
   relationship among the grouped sources is the same as the
   relationship among corresponding sources in media streams group= ed
   using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

   Several "m" lines grouped together using FID semantics form a m= edia
   flow.  A media agent handling a media flow that comprises s= everal "m"
   lines MUST send a copy of the media to every "m" line part of t= he
   flow as long as the codecs and the direction attribute present i= n a
   particular "m" line allow it.

   It is assumed that the application uses only one codec at a tim= e to
   encode the media produced.  This codec MAY change dynamica= lly during
   the session, but at any particular moment only one codec is in u= se.

   The application encodes the media using the current codec and c= hecks
   one by one all the "m" lines that are part of the flow.  I= f a
   particular "m" line contains the codec being used and the direc= tion
   attribute is "sendonly" or "sendrecv", a copy of the encoded me= dia is
   sent to the address/port specified in that particular media str= eam.
   If either the "m" line does not contain the codec being used or= the
   direction attribute is neither "sendonly" nor "sendrecv", nothi= ng is
   sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?
=



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>=

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


____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-10A6CC59-955F-4D31-94E8-2D7F50F9C270-- From nobody Wed Oct 22 12:17:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FD51AD036 for ; Wed, 22 Oct 2014 12:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkO1yiJ6Lyr3 for ; Wed, 22 Oct 2014 12:17:14 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755161AD03C for ; Wed, 22 Oct 2014 12:16:48 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so2270677wid.16 for ; Wed, 22 Oct 2014 12:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6DQW9tXYzIK+RBxL7g4ozbMDULEwsVlKyqIHZE8mp6E=; b=w6qirzGerz0Zw+2Nrj0/0HMCkBu+L6/8SuuTVYT34XyrDbk8bL7uvQBpLkLPsZXeT9 mEYpxUbyIOTczGuLA9GIB4CU8ayOA3vSw9oFtWjT5yHxaQeeF5Rh79b5jLWASzDpda7N wWKHsUuFhPMcKa5+mF6ldEWF5jCHFfbQNCPsVUtMl9rIIGEoYSIRUgbCilm5vG0VkvPM oJLqWRVStXvWt4S2YGR+OO6B8N9teLGxhzce9tMAT2d+VoUMw4+avc1qXDYKM4/WDG1H nJOlBPU3Q25PYxA4M69dM3zCa7/cl+XHmQg269WlqFlxkPeS7tAb5Qw3adRlZK1xNt6b Lx/A== MIME-Version: 1.0 X-Received: by 10.194.157.137 with SMTP id wm9mr26638wjb.5.1414005407104; Wed, 22 Oct 2014 12:16:47 -0700 (PDT) Received: by 10.194.60.134 with HTTP; Wed, 22 Oct 2014 12:16:47 -0700 (PDT) In-Reply-To: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> Date: Wed, 22 Oct 2014 12:16:47 -0700 Message-ID: From: Suhas Nandakumar To: Bernard Aboba Content-Type: multipart/alternative; boundary=089e013c6b68004253050607ca79 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/553zVXUpK8zb1q4kYhp67a_Nyeg Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 19:17:18 -0000 --089e013c6b68004253050607ca79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just thinking loud As long as there is enough information to unabigously map the incoming streams to the SDP, i dont see we need any more information to be added. I feel the combination of SSRC and Payload Type in the RTP packet is good enough to find the mapping to the appropriate media line (if the PTs are not repeated) when needed. So in the initial examples above, ssrc-group communicated in SDP along with semantics (FEC,FID) when applied to incoming SSRCs and the associated payload type has all the needed info for the receiver to demux at the rtp level as well as map at the SDP level. Thus i dont see a need for specifying PT association explicitly in SDP for the ssrc-groups. Cheers Suhas On Wed, Oct 22, 2014 at 12:01 PM, Bernard Aboba wrote: > SDP specifies payload types for RED/ULPFEC/RTX so as to allow > differentiation within an ssrc-group. So while an fmtp: attribute could b= e > used to denote a media stream on an a:ssrc line, it is not necessary. > > RFC 5176 Example 3 gives an example with two cameras in which there are > two ssrc-group lines (one for each camera), with payload type used to > differentiate between H.264 and RTX in each ssrc-group: > > > m=3Dvideo 49174 RTP/AVPF 96 98 > > a=3Drtpmap:96 H.264/90000 > > a=3Drtpmap:98 rtx/90000 > > a=3Dfmtp:98 apt=3D96;rtx-time=3D3000 > > a=3Dssrc-group:FID 11111 22222 > > a=3Dssrc:11111 cname:user3@example.com > > a=3Dssrc:22222 cname:user3@example.com > > a=3Dssrc-group:FID 33333 44444 > > a=3Dssrc:33333 cname:user3@example.com > > a=3Dssrc:44444 cname:user3@example.com > > > I believe that RFC 5176 includes the two groups to make clear that there = are two sources so that the Answerer might choose to reject the m-line if i= t cannot handle that. From RFC 5176 Section 8: > > > When used with the SDP Offer/Answer Model [RFC3264 ], SDP source-specific attributes describe only the sources t= hat each party is > willing to send (whether it is sending RTP data or RTCP report > blocks). No mechanism is provided by which an answer can accept or > reject individual sources within a media stream; if the set of > sources in a media stream is unacceptable, the answerer's only option > is to reject the media stream or the entire multimedia session. > > > Note that in the example in RFC 4588 Section 8.8 where there is only one = source, there are no ssrc-group lines at all: > > > v=3D0 > > o=3Dmascha 2980675221 2980675778 IN IP4 host.example.net > > c=3DIN IP4 192.0.2.0 > > m=3Dvideo 49170 RTP/AVPF 96 97 > > a=3Drtpmap:96 MP4V-ES/90000 > > a=3Drtcp-fb:96 nack > > a=3Dfmtp:96 profile-level-id=3D8;config=3D01010000012000884006682C2090A2= 1F > > a=3Drtpmap:97 rtx/90000 > > a=3Dfmtp:97 apt=3D96;rtx-time=3D3000 > > > The situation would be the same for FEC groups created via ssrc-group:FEC= . > From > https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux : > > The FEC and the payload MAY also be multiplexed by SSRC into one > single RTP session, with separate SSRC values, if the association > between FEC and payload streams are communicated to all members of > the session. If SDP is used, this association MAY be communicated > through the FEC ssrc-group semantic [RFC5576 ]; other mechanisms > are also possible. Receivers MUST NOT attempt to interpret FEC > streams for which they do not have information to associate them > with the corresponding payload streams. > > > > > On Oct 21, 2014, at 11:36 AM, I=C3=B1aki Baz Castillo wro= te: > > I hope I can rule my SDP logic based on standards rather than on how > Chrome implements some features. > > My question was generic: if I receive the above SDP, how do I know which > payloads each ssrc is supposed to transport? > On 21 Oct 2014 19:57, "Peter Thatcher" wrote: > >> I'm not sure where it's specified, but here's where it's implemented: >> >> >> https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/w= ebrtcvideoengine.cc#4108 >> >> It only supports 2 SSRCs for a FID group. It would ignore any more than >> that. >> >> On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo >> wrote: >> >>> How is that? Where is that specified? What about if I include 3 ssrc >>> values in the ssrc-group? What is each one for? >>> On 21 Oct 2014 19:31, "Peter Thatcher" wrote: >>> >>>> 345259865 is "real" >>>> 2693756249 is rtx >>>> >>>> On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> May I know which SSRC (345259865 or 2693756249) will be used for the >>>>> real media stream (plus RED and FEC) and which SSRC will be used for >>>>> RTX? >>>>> >>>>> >>>>> >>>>> -------------------------- >>>>> m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 >>>>> a=3Dmid:video >>>>> a=3Drtpmap:100 VP8/90000 >>>>> a=3Drtpmap:116 red/90000 >>>>> a=3Drtpmap:117 ulpfec/90000 >>>>> a=3Drtpmap:96 rtx/90000 >>>>> a=3Dfmtp:96 apt=3D100 >>>>> a=3Dssrc-group:FID 345259865 2693756249 >>>>> a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs >>>>> a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>> a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>> a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>> a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs >>>>> a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>> a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>> a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>> ------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> RFC 5576 does not clarify it at all: >>>>> >>>>> http://tools.ietf.org/html/rfc5576#section-4.2 >>>>> >>>>> -------------------------------------------------- >>>>> 4.2. The "ssrc-group" Media Attribute >>>>> >>>>> a=3Dssrc-group: ... >>>>> >>>>> [..] >>>>> >>>>> The parameter is taken from the specification of the >>>>> "group" attribute [RFC3388]. The initial semantic values defined >>>>> for >>>>> the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] >>>>> and FEC (Forward Error Correction) [RFC4756]. In each case, the >>>>> relationship among the grouped sources is the same as the >>>>> relationship among corresponding sources in media streams grouped >>>>> using the SDP "group" attribute. >>>>> -------------------------------------------------- >>>>> >>>>> >>>>> >>>>> The referenced RFC 3388 neither clarifies it: >>>>> >>>>> --------------------------------------------------- >>>>> 7.4 FID Semantics >>>>> >>>>> Several "m" lines grouped together using FID semantics form a medi= a >>>>> flow. A media agent handling a media flow that comprises several >>>>> "m" >>>>> lines MUST send a copy of the media to every "m" line part of the >>>>> flow as long as the codecs and the direction attribute present in = a >>>>> particular "m" line allow it. >>>>> >>>>> It is assumed that the application uses only one codec at a time t= o >>>>> encode the media produced. This codec MAY change dynamically duri= ng >>>>> the session, but at any particular moment only one codec is in use= . >>>>> >>>>> The application encodes the media using the current codec and chec= ks >>>>> one by one all the "m" lines that are part of the flow. If a >>>>> particular "m" line contains the codec being used and the directio= n >>>>> attribute is "sendonly" or "sendrecv", a copy of the encoded media >>>>> is >>>>> sent to the address/port specified in that particular media stream= . >>>>> If either the "m" line does not contain the codec being used or th= e >>>>> direction attribute is neither "sendonly" nor "sendrecv", nothing = is >>>>> sent over this media stream. >>>>> ---------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> So, how is the usage of ssrc-group? Where is it really defined? >>>>> >>>>> Can I put more than 2 ssrc together in the same ssrc-group line? >>>>> >>>>> How should the receiver interpret it? >>>>> >>>>> Does a ssrc-group always mean RTX usage? Where is that specified in >>>>> the above SDP? >>>>> >>>>> Does not the above SDP look a complete mixture of hacks and >>>>> workarounds? >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> I=C3=B1aki Baz Castillo >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > --089e013c6b68004253050607ca79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just thinking loud=C2=A0
=C2=A0As long as there is eno= ugh information to unabigously map the incoming streams to the SDP, i dont = see we need any more information to be added.

I fe= el the combination of SSRC and Payload Type in the RTP packet is good enoug= h to find the mapping to the appropriate media line (if the PTs are not rep= eated) when needed.

So in the initial examples abo= ve, ssrc-group communicated in SDP along with semantics (FEC,FID) when appl= ied to incoming SSRCs and the associated payload type has all the needed in= fo for the receiver to demux at the rtp level as well as map at the SDP lev= el. Thus i dont see a need for specifying PT association explicitly in SDP = for the ssrc-groups.

Cheers
Suhas
<= /div>

On Wed, Oct = 22, 2014 at 12:01 PM, Bernard Aboba <bernard.aboba@gmail.com>= wrote:
SDP= specifies payload types for RED/ULPFEC/RTX so as to allow differentiation = within an ssrc-group. So while an fmtp: attribute could be used to denote a= media stream on an a:ssrc line, it is not necessary.

<= div>RFC 5176 Example 3 gives an example with two cameras in which there are= two ssrc-group lines (one for each camera), with payload type used to diff= erentiate between H.264 and RTX in each ssrc-group:


   m=3Dvideo 49174 RTP/AVPF 96 98=C2=A0
=C2=A0a=
=3Drtpmap:96 H.264/90000=C2=A0
=C2=A0a=3Drtpmap:9=
8 rtx/90000=C2=A0
=C2=A0a=3Dfmtp:98 apt=3D96;rtx-=
time=3D3000=C2=A0
=C2=A0a=3Dssrc-group:FID 11111 =
22222=C2=A0
=C2=A0a=3Dssrc:11111 cname:user3@example.com=C2=A0
=C2=A0a=3Dssrc:22222 cname:user3@example.com=C2=A0
=
=C2=A0a=3Dssrc-group:FID 33333 44444=C2=A0
=C2=A0=
a=3Dssrc:33333 cname:user3@example.com=C2=A0
=C2=A0a=3Dssrc:44444 cname=
:user3@example.com


I believe that RFC 5176 =
includes the two groups to make clear that there are two sources so that th=
e Answerer might choose to reject the m-line if it cannot handle that.=C2=
=A0From RFC 5176 Section 8:

When used with the SDP Offer/A=
nswer Model [RFC3264], SDP source-specific attributes describe only the sources that=
 each party is
   willing to send (whether it is sending RTP data or RTCP report
   blocks).  No mechanism is provided by which an answer can accept or
   reject individual sources within a media stream; if the set of
   sources in a media stream is unacceptable, the answerer's only optio=
n
   is to reject the media stream or the entire multimedia session.

Note that in the example in RFC 4588=
 Section 8.8 where there is only one source, there are no ssrc-group lines =
at all:

=C2=A0v=3D0=C2=A0
=

=C2=A0o=3Dmascha 2980675221 2980675778 IN IP4 host.example.net=C2=A0
=C2=
=A0c=3DIN IP4 192.0.2.0=C2=A0
=C2=A0m=3Dvideo 49170 RTP/AVP=
F 96 97=C2=A0
<=
span style=3D"white-space:normal;background-color:rgba(255,255,255,0);font-=
family:UICTFontTextStyleBody">=C2=A0a=3Drtpmap:96 MP4V-ES/90000=C2=A0
=C2=A0a=3Drtcp-fb:96 nack=C2=A0
=C2=A0a=3Dfmtp:9=
6 profile-level-id=3D8;config=3D01010000012000884006682C2090A21F=C2=A0
=C2=A0a=3Drtpmap:97 rtx/90000=C2=A0
=C2=A0a=3Df=
mtp:97 apt=3D96;rtx-time=3D3000

The s= ituation would be the same for FEC groups created via ssrc-group:FEC. From= =C2=A0

      The =
FEC and the payload MAY also be multiplexed by SSRC into one
      single RTP session, with separate SSRC values, if the association
      between FEC and payload streams are communicated to all members of
      the session.  If SDP is used, this association MAY be communicated
      through the FEC ssrc-group semantic [RFC5576]; other=
 mechanisms
      are also possible.  Receivers MUST NOT attempt to interpret FEC
      streams for which they do not have information to associate them
      with the corresponding payload streams.



On Oct 21, 2014, at 11:36 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

I hope I can rule my S= DP logic based on standards rather than on how Chrome implements some featu= res.

My question was generic: if I receive the above SDP, how do = I know which payloads each ssrc is supposed to transport?

On 21 Oct 2014 19:57, "Peter Thatcher"= <pthatcher@go= ogle.com> wrote:
I'm not sure where it's specified, but here= 's where it's implemented:

https://code.google.com/p/webrtc/source/browse= /trunk/talk/media/webrtc/webrtcvideoengine.cc#4108

It only supports 2 SSRCs for a FID group.=C2=A0 It would ignore an= y more than that.

On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castill= o <= ibc@aliax.net> wrote:

How is that? Where is that specified? What about if I include 3 s= src values in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher"= <pthatcher@go= ogle.com> wrote:
345259865 is "real"
2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net&g= t; wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.=C2=A0 The "ssrc-group" Media Attribute

=C2=A0 =C2=A0a=3Dssrc-group:<semantics> <ssrc-id> ...

=C2=A0 =C2=A0[..]

=C2=A0 =C2=A0The <semantics> parameter is taken from the specificatio= n of the
=C2=A0 =C2=A0"group" attribute [RFC3388].=C2=A0 The initial seman= tic values defined for
=C2=A0 =C2=A0the "ssrc-group" attribute are FID (Flow Identificat= ion) [RFC3388]
=C2=A0 =C2=A0and FEC (Forward Error Correction) [RFC4756].=C2=A0 In each ca= se, the
=C2=A0 =C2=A0relationship among the grouped sources is the same as the
=C2=A0 =C2=A0relationship among corresponding sources in media streams grou= ped
=C2=A0 =C2=A0using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

=C2=A0 =C2=A0Several "m" lines grouped together using FID semanti= cs form a media
=C2=A0 =C2=A0flow.=C2=A0 A media agent handling a media flow that comprises= several "m"
=C2=A0 =C2=A0lines MUST send a copy of the media to every "m" lin= e part of the
=C2=A0 =C2=A0flow as long as the codecs and the direction attribute present= in a
=C2=A0 =C2=A0particular "m" line allow it.

=C2=A0 =C2=A0It is assumed that the application uses only one codec at a ti= me to
=C2=A0 =C2=A0encode the media produced.=C2=A0 This codec MAY change dynamic= ally during
=C2=A0 =C2=A0the session, but at any particular moment only one codec is in= use.

=C2=A0 =C2=A0The application encodes the media using the current codec and = checks
=C2=A0 =C2=A0one by one all the "m" lines that are part of the fl= ow.=C2=A0 If a
=C2=A0 =C2=A0particular "m" line contains the codec being used an= d the direction
=C2=A0 =C2=A0attribute is "sendonly" or "sendrecv", a c= opy of the encoded media is
=C2=A0 =C2=A0sent to the address/port specified in that particular media st= ream.
=C2=A0 =C2=A0If either the "m" line does not contain the codec be= ing used or the
=C2=A0 =C2=A0direction attribute is neither "sendonly" nor "= sendrecv", nothing is
=C2=A0 =C2=A0sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;

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


___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/rtcweb=

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


--089e013c6b68004253050607ca79-- From nobody Wed Oct 22 12:29:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F101AD39D for ; Wed, 22 Oct 2014 12:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLE-0g0U_bTa for ; Wed, 22 Oct 2014 12:29:03 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984121AD38E for ; Wed, 22 Oct 2014 12:29:02 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id y13so2077064pdi.34 for ; Wed, 22 Oct 2014 12:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nd0suSSfxWVqlBtzrM9xQHIvsjl7O95pnbDgGrdNdUA=; b=tjkgT8/lZpX3VOnmbFwXmzoGAzHQtRUwztkRbglwdSYPt6FS2l3U8KK3UBKXicQ+zB hHLVx/PDO7bC+WNxTZAPPkLCTfbumV1uVq2nufqUlXXgdyFP+BlqgsWJrFZrInd56aPf 5oREI9cjmjREPsOlGbgpdTfLsW6gnmcgcvxs4stu0RveTdzyTic2KweXWOlj8J4DIDim 2s0kl5T/0f/F/OO5AsKLyhANp07Bn+sLJ9AUTqZ0CkQTNqe5n9ZuByy60rgHye24si9S brH47VfknCTx66UFmT67/ZeXyb22Jla0KWkAb+eR3rsVXqLpiJJI/ZSn+JMgn24cY2lk ElKQ== X-Received: by 10.70.123.228 with SMTP id md4mr3695258pdb.159.1414006142229; Wed, 22 Oct 2014 12:29:02 -0700 (PDT) Received: from [192.168.1.113] (71-94-170-52.dhcp.knwc.wa.charter.com. [71.94.170.52]) by mx.google.com with ESMTPSA id yp10sm15107410pac.18.2014.10.22.12.29.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 12:29:00 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-2A882D09-CDCC-4215-945C-DD45A989E264 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12B410) In-Reply-To: Date: Wed, 22 Oct 2014 12:28:59 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5A936EB2-EC94-49BD-AF11-E5A5141D77BE@gmail.com> References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> To: Suhas Nandakumar Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/S67pKijE_RcllfzwDvLQ5BgXhTo Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 19:29:07 -0000 --Apple-Mail-2A882D09-CDCC-4215-945C-DD45A989E264 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree. The SSRC-groups are included only to make it clear which FEC/RED/RT= X streams go with which media streams in the multiple source case. As long a= s payload types are distinct we have all the information we need. > On Oct 22, 2014, at 12:16 PM, Suhas Nandakumar wrote= : >=20 > Just thinking loud=20 > As long as there is enough information to unabigously map the incoming st= reams to the SDP, i dont see we need any more information to be added. >=20 > I feel the combination of SSRC and Payload Type in the RTP packet is good e= nough to find the mapping to the appropriate media line (if the PTs are not r= epeated) when needed. >=20 > So in the initial examples above, ssrc-group communicated in SDP along wit= h semantics (FEC,FID) when applied to incoming SSRCs and the associated payl= oad type has all the needed info for the receiver to demux at the rtp level a= s well as map at the SDP level. Thus i dont see a need for specifying PT ass= ociation explicitly in SDP for the ssrc-groups. >=20 > Cheers > Suhas >=20 >> On Wed, Oct 22, 2014 at 12:01 PM, Bernard Aboba = wrote: >> SDP specifies payload types for RED/ULPFEC/RTX so as to allow differentia= tion within an ssrc-group. So while an fmtp: attribute could be used to deno= te a media stream on an a:ssrc line, it is not necessary. >>=20 >> RFC 5176 Example 3 gives an example with two cameras in which there are t= wo ssrc-group lines (one for each camera), with payload type used to differe= ntiate between H.264 and RTX in each ssrc-group: >>=20 >> m=3Dvideo 49174 RTP/AVPF 96 98=20 >> a=3Drtpmap:96 H.264/90000=20 >> a=3Drtpmap:98 rtx/90000=20 >> a=3Dfmtp:98 apt=3D96;rtx-time=3D3000=20 >> a=3Dssrc-group:FID 11111 22222=20 >> a=3Dssrc:11111 cname:user3@example.com=20 >> a=3Dssrc:22222 cname:user3@example.com=20 >> a=3Dssrc-group:FID 33333 44444=20 >> a=3Dssrc:33333 cname:user3@example.com=20 >> a=3Dssrc:44444 cname:user3@example.com >>=20 >> I believe that RFC 5176 includes the two groups to make clear that there a= re two sources so that the Answerer might choose to reject the m-line if it c= annot handle that. =46rom RFC 5176 Section 8: >>=20 >> When used with the SDP Offer/Answer Model [RFC3264], SDP source-specific a= ttributes describe only the sources that each party is willing to send (whet= her it is sending RTP data or RTCP report blocks). No mechanism is provided b= y which an answer can accept or reject individual sources within a media str= eam; if the set of sources in a media stream is unacceptable, the answerer's= only option is to reject the media stream or the entire multimedia session.= >>=20 >> Note that in the example in RFC 4588 Section 8.8 where there is only one s= ource, there are no ssrc-group lines at all: >>=20 >> v=3D0=20 >> o=3Dmascha 2980675221 2980675778 IN IP4 host.example.net=20 >> c=3DIN IP4 192.0.2.0=20 >> m=3Dvideo 49170 RTP/AVPF 96 97=20 >> a=3Drtpmap:96 MP4V-ES/90000=20 >> a=3Drtcp-fb:96 nack=20 >> a=3Dfmtp:96 profile-level-id=3D8;config=3D01010000012000884006682C2090A2= 1F=20 >> a=3Drtpmap:97 rtx/90000=20 >> a=3Dfmtp:97 apt=3D96;rtx-time=3D3000 >>=20 >> The situation would be the same for FEC groups created via ssrc-group:FEC= . =46rom=20 >> https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux : >>=20 >> The FEC and the payload MAY also be multiplexed by SSRC into one single R= TP session, with separate SSRC values, if the association between FEC and pa= yload streams are communicated to all members of the session. If SDP is used= , this association MAY be communicated through the FEC ssrc-group semantic [= RFC5576]; other mechanisms are also possible. Receivers MUST NOT attempt to i= nterpret FEC streams for which they do not have information to associate the= m with the corresponding payload streams. >>=20 >>=20 >>=20 >>> On Oct 21, 2014, at 11:36 AM, I=C3=B1aki Baz Castillo wr= ote: >>>=20 >>> I hope I can rule my SDP logic based on standards rather than on how Chr= ome implements some features. >>>=20 >>> My question was generic: if I receive the above SDP, how do I know which= payloads each ssrc is supposed to transport? >>>=20 >>>> On 21 Oct 2014 19:57, "Peter Thatcher" wrote: >>>> I'm not sure where it's specified, but here's where it's implemented: >>>>=20 >>>> https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/= webrtcvideoengine.cc#4108 >>>>=20 >>>> It only supports 2 SSRCs for a FID group. It would ignore any more tha= n that. >>>>=20 >>>>> On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo wrote: >>>>> How is that? Where is that specified? What about if I include 3 ssrc v= alues in the ssrc-group? What is each one for? >>>>>=20 >>>>>> On 21 Oct 2014 19:31, "Peter Thatcher" wrote: >>>>>> 345259865 is "real" >>>>>> 2693756249 is rtx >>>>>>=20 >>>>>>> On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> May I know which SSRC (345259865 or 2693756249) will be used for the= >>>>>>> real media stream (plus RED and FEC) and which SSRC will be used for= >>>>>>> RTX? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -------------------------- >>>>>>> m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 >>>>>>> a=3Dmid:video >>>>>>> a=3Drtpmap:100 VP8/90000 >>>>>>> a=3Drtpmap:116 red/90000 >>>>>>> a=3Drtpmap:117 ulpfec/90000 >>>>>>> a=3Drtpmap:96 rtx/90000 >>>>>>> a=3Dfmtp:96 apt=3D100 >>>>>>> a=3Dssrc-group:FID 345259865 2693756249 >>>>>>> a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs >>>>>>> a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>>>> a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>>>> a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>>>> a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs >>>>>>> a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>>>> a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>>>> a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>>>> ------------------------------- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> RFC 5576 does not clarify it at all: >>>>>>>=20 >>>>>>> http://tools.ietf.org/html/rfc5576#section-4.2 >>>>>>>=20 >>>>>>> -------------------------------------------------- >>>>>>> 4.2. The "ssrc-group" Media Attribute >>>>>>>=20 >>>>>>> a=3Dssrc-group: ... >>>>>>>=20 >>>>>>> [..] >>>>>>>=20 >>>>>>> The parameter is taken from the specification of the >>>>>>> "group" attribute [RFC3388]. The initial semantic values defined= for >>>>>>> the "ssrc-group" attribute are FID (Flow Identification) [RFC3388= ] >>>>>>> and FEC (Forward Error Correction) [RFC4756]. In each case, the >>>>>>> relationship among the grouped sources is the same as the >>>>>>> relationship among corresponding sources in media streams grouped= >>>>>>> using the SDP "group" attribute. >>>>>>> -------------------------------------------------- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The referenced RFC 3388 neither clarifies it: >>>>>>>=20 >>>>>>> --------------------------------------------------- >>>>>>> 7.4 FID Semantics >>>>>>>=20 >>>>>>> Several "m" lines grouped together using FID semantics form a med= ia >>>>>>> flow. A media agent handling a media flow that comprises several= "m" >>>>>>> lines MUST send a copy of the media to every "m" line part of the= >>>>>>> flow as long as the codecs and the direction attribute present in= a >>>>>>> particular "m" line allow it. >>>>>>>=20 >>>>>>> It is assumed that the application uses only one codec at a time t= o >>>>>>> encode the media produced. This codec MAY change dynamically dur= ing >>>>>>> the session, but at any particular moment only one codec is in us= e. >>>>>>>=20 >>>>>>> The application encodes the media using the current codec and che= cks >>>>>>> one by one all the "m" lines that are part of the flow. If a >>>>>>> particular "m" line contains the codec being used and the directi= on >>>>>>> attribute is "sendonly" or "sendrecv", a copy of the encoded medi= a is >>>>>>> sent to the address/port specified in that particular media strea= m. >>>>>>> If either the "m" line does not contain the codec being used or t= he >>>>>>> direction attribute is neither "sendonly" nor "sendrecv", nothing= is >>>>>>> sent over this media stream. >>>>>>> ---------------------------------------------------- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> So, how is the usage of ssrc-group? Where is it really defined? >>>>>>>=20 >>>>>>> Can I put more than 2 ssrc together in the same ssrc-group line? >>>>>>>=20 >>>>>>> How should the receiver interpret it? >>>>>>>=20 >>>>>>> Does a ssrc-group always mean RTX usage? Where is that specified in >>>>>>> the above SDP? >>>>>>>=20 >>>>>>> Does not the above SDP look a complete mixture of hacks and workarou= nds? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> I=C3=B1aki Baz Castillo >>>>>>> >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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 >=20 --Apple-Mail-2A882D09-CDCC-4215-945C-DD45A989E264 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree. The SSRC-groups are included o= nly to make it clear which FEC/RED/RTX streams go with which media streams i= n the multiple source case. As long as payload types are distinct we have al= l the information we need.

On Oct 22, 2014, at 12:16 PM, S= uhas Nandakumar <suhasietf@gmail.c= om> wrote:

Just thinking loud 
 As long as there is enough information= to unabigously map the incoming streams to the SDP, i dont see we need any m= ore information to be added.

I feel the combination= of SSRC and Payload Type in the RTP packet is good enough to find the mappi= ng to the appropriate media line (if the PTs are not repeated) when needed.<= /div>

So in the initial examples above, ssrc-group commun= icated in SDP along with semantics (FEC,FID) when applied to incoming SSRCs a= nd the associated payload type has all the needed info for the receiver to d= emux at the rtp level as well as map at the SDP level. Thus i dont see a nee= d for specifying PT association explicitly in SDP for the ssrc-groups.
=

Cheers
Suhas

On Wed, Oct 22, 2014 at 12:01 PM, Bernar= d Aboba <bernard.aboba@gmail.com> wrote:
SDP specifies payload types for RED/= ULPFEC/RTX so as to allow differentiation within an ssrc-group. So while an f= mtp: attribute could be used to denote a media stream on an a:ssrc line, it i= s not necessary.

RFC 5176 Example 3 gives an exampl= e with two cameras in which there are two ssrc-group lines (one for each cam= era), with payload type used to differentiate between H.264 and RTX in each s= src-group:


   m=3Dvideo 49174 RTP/AVPF 96 98 
 a=3Drt=
pmap:96 H.264/90000 
 a=3Drtpmap:98 rtx/90=
000 
 a=3Dfmtp:98 apt=3D96;rtx-time=3D3000=
 
 a=3Dssrc-group:FID 11111 22222 
 a=3Dssrc:11111 cname:user3@example.com 
=
&nbs=
p;a=3Dssrc:22222 cname:user3@example.com 
 a=3Dssrc-group:FID 333=
33 44444 
 a=3Dssrc:33333 cname:user3@example.com 
 a=3Dssrc:44444 cname:user3@example.com


I believe that RFC 5176 inclu=
des the two groups to make clear that there are two sources so that the Answ=
erer might choose to reject the m-line if it cannot handle that. =46rom RFC 5176 Section 8:

When used with the SDP Offer/Answer Model [<=
/span>RFC3264], SDP s=
ource-specific attributes describe only the sources that each party is
   willing to send (whether it is sending RTP data or RTCP report
   blocks).  No mechanism is provided by which an answer can accept or
   reject individual sources within a media stream; if the set of
   sources in a media stream is unacceptable, the answerer's only option
   is to reject the media stream or the entire multimedia session.

Note that in the example in RFC 4588 Secti=
on 8.8 where there is only one source, there are no ssrc-group lines at all:=


 v=3D0 
 o=3Dm=
ascha 2980675221 2980675778 IN IP4 host.example.net 
 c=3DIN IP4 192.0=
.2.0 
 m=3Dvideo 49170 RTP/AVPF 96 97 
 a=3Drtpmap:96 MP4V-ES/90000 
 a=3Drtcp-f=
b:96 nack 
=
 a=3Dfmtp:96 profile-level-id=3D8;config=3D=
01010000012000884006682C2090A21F 
 a=3Drtpmap:97 rtx=
/90000 
 a=3Dfmtp:97 apt=3D96;rtx-time=3D3000=

The situation would be the same for FEC grou= ps created via ssrc-group:FEC. From 
= 
      The FEC and the payload MAY also be multiplexed by=
 SSRC into one
      single RTP session, with separate SSRC values, if the association
      between FEC and payload streams are communicated to all members of
      the session.  If SDP is used, this association MAY be communicated
      through the FEC ssrc-group semantic [RFC5576]; other me=
chanisms
      are also possible.  Receivers MUST NOT attempt to interpret FEC
      streams for which they do not have information to associate them
      with the corresponding payload streams.



On Oct 21, 2014, at 11:36 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

I hope I can rule my SDP l= ogic based on standards rather than on how Chrome implements some features.<= /p>

My question was generic: if I receive the above SDP, how do I= know which payloads each ssrc is supposed to transport?

On 21 Oct 2014 19:57, "Peter Thatcher" <pthatcher@google.com= > wrote:
I'm not sure where it's specified, but here's where it's implemented:=

https://co= de.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengi= ne.cc#4108

It only supports 2 SSRCs for a FID= group.  It would ignore any more than that.

On Tue, Oct 21, 2014 at 10= :40 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

How is that? Where is that specified? W= hat about if I include 3 ssrc values in the ssrc-group? What is each one for= ?

On 21 Oct 2014 19:31, "Peter Thatcher" <pthatcher@google.com= > wrote:
345259865 is "real"
2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, I= =C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.  The "ssrc-group" Media Attribute

   a=3Dssrc-group:<semantics> <ssrc-id> ...

   [..]

   The <semantics> parameter is taken from the specification= of the
   "group" attribute [RFC3388].  The initial semantic values d= efined for
   the "ssrc-group" attribute are FID (Flow Identification) [RFC33= 88]
   and FEC (Forward Error Correction) [RFC4756].  In each cas= e, the
   relationship among the grouped sources is the same as the
   relationship among corresponding sources in media streams group= ed
   using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

   Several "m" lines grouped together using FID semantics form a m= edia
   flow.  A media agent handling a media flow that comprises s= everal "m"
   lines MUST send a copy of the media to every "m" line part of t= he
   flow as long as the codecs and the direction attribute present i= n a
   particular "m" line allow it.

   It is assumed that the application uses only one codec at a tim= e to
   encode the media produced.  This codec MAY change dynamica= lly during
   the session, but at any particular moment only one codec is in u= se.

   The application encodes the media using the current codec and c= hecks
   one by one all the "m" lines that are part of the flow.  I= f a
   particular "m" line contains the codec being used and the direc= tion
   attribute is "sendonly" or "sendrecv", a copy of the encoded me= dia is
   sent to the address/port specified in that particular media str= eam.
   If either the "m" line does not contain the codec being used or= the
   direction attribute is neither "sendonly" nor "sendrecv", nothi= ng is
   sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?
=



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>=

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


____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org=
https://www.ietf.org/mailman/listinfo/rtcweb
<= /div>

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


= --Apple-Mail-2A882D09-CDCC-4215-945C-DD45A989E264-- From nobody Wed Oct 22 12:34:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4391AD3B3 for ; Wed, 22 Oct 2014 12:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPDJW13h2YU5 for ; Wed, 22 Oct 2014 12:34:39 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC491AD044 for ; Wed, 22 Oct 2014 12:34:38 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so4433463wgh.23 for ; Wed, 22 Oct 2014 12:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=ar9BYKJcQ5e7ep/+/aywIc2wKnI4j4FQp+3MGfRpyQk=; b=vmaFym2op5IIe9xeHXJIvYejz4cztHvZyV4qeKRgvqsWJHXYaO78l/3R7Kc/U4xAAT RBRLfWImjqxYYDPk4REV91Vy2thUKOI1ZZHeN/VHpJWuSmYrWUfeulnoUtUBZwgD16Ho mEosK4JTp4wRuwbVYGkMUFKvC3zGfdpjyB0GwAN5shSFDvq17h1J8GoRU01hI4ts1NRE nXp84V/aC0qNdsM5N8l6cmAXeVD9rH6VEqh4aU6dEtPniWT0Z8Vz7q7PgpAjKjpJpuVB 3EFml57qAOmYurYqIZzJ4iz6m0vi9GWwlsF0P4boyUMDuahKCgFhwbV8gzBMNNJTdBCS hUvQ== X-Received: by 10.194.250.105 with SMTP id zb9mr5704527wjc.123.1414006477428; Wed, 22 Oct 2014 12:34:37 -0700 (PDT) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id fv2sm165871wib.2.2014.10.22.12.34.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 12:34:36 -0700 (PDT) Message-ID: <544806D1.8010606@gmail.com> Date: Wed, 22 Oct 2014 21:34:41 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <5A936EB2-EC94-49BD-AF11-E5A5141D77BE@gmail.com> In-Reply-To: <5A936EB2-EC94-49BD-AF11-E5A5141D77BE@gmail.com> Content-Type: multipart/alternative; boundary="------------070303030708080500070802" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/p20nzIeB53gW4kPftE3jjTF-PpA Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 19:34:43 -0000 This is a multi-part message in MIME format. --------------070303030708080500070802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, I disagree, It is not possible just by looking at the SDP to know which ssrc is from the media and which is from rtx. While for WebRTC-endpoints it may be irrelevant because, as you say, you can wait for the RTP data to check the payload type and match the ssrc, we have seen that it is a must have for interoperability with ORTC. Best regards Sergio On 22/10/2014 21:28, Bernard Aboba wrote: > I agree. The SSRC-groups are included only to make it clear which > FEC/RED/RTX streams go with which media streams in the multiple source > case. As long as payload types are distinct we have all the > information we need. > > On Oct 22, 2014, at 12:16 PM, Suhas Nandakumar > wrote: > >> Just thinking loud >> As long as there is enough information to unabigously map the >> incoming streams to the SDP, i dont see we need any more information >> to be added. >> >> I feel the combination of SSRC and Payload Type in the RTP packet is >> good enough to find the mapping to the appropriate media line (if the >> PTs are not repeated) when needed. >> >> So in the initial examples above, ssrc-group communicated in SDP >> along with semantics (FEC,FID) when applied to incoming SSRCs and the >> associated payload type has all the needed info for the receiver to >> demux at the rtp level as well as map at the SDP level. Thus i dont >> see a need for specifying PT association explicitly in SDP for the >> ssrc-groups. >> >> Cheers >> Suhas >> >> On Wed, Oct 22, 2014 at 12:01 PM, Bernard Aboba >> > wrote: >> >> SDP specifies payload types for RED/ULPFEC/RTX so as to allow >> differentiation within an ssrc-group. So while an fmtp: attribute >> could be used to denote a media stream on an a:ssrc line, it is >> not necessary. >> >> RFC 5176 Example 3 gives an example with two cameras in which >> there are two ssrc-group lines (one for each camera), with >> payload type used to differentiate between H.264 and RTX in each >> ssrc-group: >> >> >> m=video 49174 RTP/AVPF 96 98 >> >> a=rtpmap:96 H.264/90000 >> >> a=rtpmap:98 rtx/90000 >> >> a=fmtp:98 apt=96;rtx-time=3000 >> >> a=ssrc-group:FID 11111 22222 >> >> a=ssrc:11111 cname:user3@example.com >> >> a=ssrc:22222 cname:user3@example.com >> >> a=ssrc-group:FID 33333 44444 >> >> a=ssrc:33333 cname:user3@example.com >> >> a=ssrc:44444 cname:user3@example.com >> >> >> I believe that RFC 5176 includes the two groups to make clear that there are two sources so that the Answerer might choose to reject the m-line if it cannot handle that. From RFC 5176 Section 8: >> >> >> When used with the SDP Offer/Answer Model [RFC3264 ], SDP source-specific attributes describe only the sources that each party is >> willing to send (whether it is sending RTP data or RTCP report >> blocks). No mechanism is provided by which an answer can accept or >> reject individual sources within a media stream; if the set of >> sources in a media stream is unacceptable, the answerer's only option >> is to reject the media stream or the entire multimedia session. >> >> >> Note that in the example in RFC 4588 Section 8.8 where there is only one source, there are no ssrc-group lines at all: >> >> >> v=0 >> >> o=mascha 2980675221 2980675778 IN IP4host.example.net >> >> c=IN IP4 192.0.2.0 >> >> m=video 49170 RTP/AVPF 96 97 >> >> a=rtpmap:96 MP4V-ES/90000 >> >> a=rtcp-fb:96 nack >> >> a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F >> >> a=rtpmap:97 rtx/90000 >> >> a=fmtp:97 apt=96;rtx-time=3000 >> >> >> The situation would be the same for FEC groups created via >> ssrc-group:FEC. From >> https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux : >> >> The FEC and the payload MAY also be multiplexed by SSRC into one >> single RTP session, with separate SSRC values, if the association >> between FEC and payload streams are communicated to all members of >> the session. If SDP is used, this association MAY be communicated >> through the FEC ssrc-group semantic [RFC5576 ]; other mechanisms >> are also possible. Receivers MUST NOT attempt to interpret FEC >> streams for which they do not have information to associate them >> with the corresponding payload streams. >> >> >> >> >> On Oct 21, 2014, at 11:36 AM, Iñaki Baz Castillo > > wrote: >> >>> I hope I can rule my SDP logic based on standards rather than on >>> how Chrome implements some features. >>> >>> My question was generic: if I receive the above SDP, how do I >>> know which payloads each ssrc is supposed to transport? >>> >>> On 21 Oct 2014 19:57, "Peter Thatcher" >> > wrote: >>> >>> I'm not sure where it's specified, but here's where it's >>> implemented: >>> >>> https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengine.cc#4108 >>> >>> It only supports 2 SSRCs for a FID group. It would ignore >>> any more than that. >>> >>> On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo >>> > wrote: >>> >>> How is that? Where is that specified? What about if I >>> include 3 ssrc values in the ssrc-group? What is each >>> one for? >>> >>> On 21 Oct 2014 19:31, "Peter Thatcher" >>> > wrote: >>> >>> 345259865 is "real" >>> 2693756249 is rtx >>> >>> On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo >>> > wrote: >>> >>> Hi, >>> >>> May I know which SSRC (345259865 or 2693756249 >>> ) will be used for the >>> real media stream (plus RED and FEC) and which >>> SSRC will be used for >>> RTX? >>> >>> >>> >>> -------------------------- >>> m=video 62164 RTP/SAVPF 100 116 117 96 >>> a=mid:video >>> a=rtpmap:100 VP8/90000 >>> a=rtpmap:116 red/90000 >>> a=rtpmap:117 ulpfec/90000 >>> a=rtpmap:96 rtx/90000 >>> a=fmtp:96 apt=100 >>> a=ssrc-group:FID 345259865 2693756249 >>> >>> a=ssrc:345259865 cname:erS7E/KHLYKTejNs >>> a=ssrc:345259865 >>> msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> a=ssrc:345259865 >>> mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> a=ssrc:345259865 >>> label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> a=ssrc:2693756249 >>> cname:erS7E/KHLYKTejNs >>> a=ssrc:2693756249 >>> msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> a=ssrc:2693756249 >>> mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>> a=ssrc:2693756249 >>> label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>> ------------------------------- >>> >>> >>> >>> >>> RFC 5576 does not clarify it at all: >>> >>> http://tools.ietf.org/html/rfc5576#section-4.2 >>> >>> -------------------------------------------------- >>> 4.2. The "ssrc-group" Media Attribute >>> >>> a=ssrc-group: ... >>> >>> [..] >>> >>> The parameter is taken from the >>> specification of the >>> "group" attribute [RFC3388]. The initial >>> semantic values defined for >>> the "ssrc-group" attribute are FID (Flow >>> Identification) [RFC3388] >>> and FEC (Forward Error Correction) >>> [RFC4756]. In each case, the >>> relationship among the grouped sources is the >>> same as the >>> relationship among corresponding sources in >>> media streams grouped >>> using the SDP "group" attribute. >>> -------------------------------------------------- >>> >>> >>> >>> The referenced RFC 3388 neither clarifies it: >>> >>> --------------------------------------------------- >>> 7.4 FID Semantics >>> >>> Several "m" lines grouped together using FID >>> semantics form a media >>> flow. A media agent handling a media flow >>> that comprises several "m" >>> lines MUST send a copy of the media to every >>> "m" line part of the >>> flow as long as the codecs and the direction >>> attribute present in a >>> particular "m" line allow it. >>> >>> It is assumed that the application uses only >>> one codec at a time to >>> encode the media produced. This codec MAY >>> change dynamically during >>> the session, but at any particular moment >>> only one codec is in use. >>> >>> The application encodes the media using the >>> current codec and checks >>> one by one all the "m" lines that are part of >>> the flow. If a >>> particular "m" line contains the codec being >>> used and the direction >>> attribute is "sendonly" or "sendrecv", a copy >>> of the encoded media is >>> sent to the address/port specified in that >>> particular media stream. >>> If either the "m" line does not contain the >>> codec being used or the >>> direction attribute is neither "sendonly" nor >>> "sendrecv", nothing is >>> sent over this media stream. >>> ---------------------------------------------------- >>> >>> >>> >>> >>> So, how is the usage of ssrc-group? Where is it >>> really defined? >>> >>> Can I put more than 2 ssrc together in the same >>> ssrc-group line? >>> >>> How should the receiver interpret it? >>> >>> Does a ssrc-group always mean RTX usage? Where >>> is that specified in >>> the above SDP? >>> >>> Does not the above SDP look a complete mixture >>> of hacks and workarounds? >>> >>> >>> >>> >>> -- >>> Iñaki Baz Castillo >>> > >>> >>> _______________________________________________ >>> 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 --------------070303030708080500070802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

I disagree, It is not possible just by looking at the SDP to know which ssrc is from the media and which is from rtx. While for WebRTC-endpoints it may be irrelevant because, as you say, you can wait for the RTP data to check the payload type and match the ssrc, we have seen that it is a must have for interoperability with ORTC.

Best regards
Sergio
On 22/10/2014 21:28, Bernard Aboba wrote:
I agree. The SSRC-groups are included only to make it clear which FEC/RED/RTX streams go with which media streams in the multiple source case. As long as payload types are distinct we have all the information we need.

On Oct 22, 2014, at 12:16 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:

Just thinking loud 
 As long as there is enough information to unabigously map the incoming streams to the SDP, i dont see we need any more information to be added.

I feel the combination of SSRC and Payload Type in the RTP packet is good enough to find the mapping to the appropriate media line (if the PTs are not repeated) when needed.

So in the initial examples above, ssrc-group communicated in SDP along with semantics (FEC,FID) when applied to incoming SSRCs and the associated payload type has all the needed info for the receiver to demux at the rtp level as well as map at the SDP level. Thus i dont see a need for specifying PT association explicitly in SDP for the ssrc-groups.

Cheers
Suhas

On Wed, Oct 22, 2014 at 12:01 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
SDP specifies payload types for RED/ULPFEC/RTX so as to allow differentiation within an ssrc-group. So while an fmtp: attribute could be used to denote a media stream on an a:ssrc line, it is not necessary.

RFC 5176 Example 3 gives an example with two cameras in which there are two ssrc-group lines (one for each camera), with payload type used to differentiate between H.264 and RTX in each ssrc-group:


   m=video 49174 RTP/AVPF 96 98 
 a=rtpmap:96 H.264/90000 
 a=rtpmap:98 rtx/90000 
 a=fmtp:98 apt=96;rtx-time=3000 
 a=ssrc-group:FID 11111 22222 
 a=ssrc:11111 cname:user3@example.com 
 a=ssrc:22222 cname:user3@example.com 
 a=ssrc-group:FID 33333 44444 
 a=ssrc:33333 cname:user3@example.com 
 a=ssrc:44444 cname:user3@example.com



I believe that RFC 5176 includes the two groups to make clear that there are two sources so that the Answerer might choose to reject the m-line if it cannot handle that. From RFC 5176 Section 8:


When used with the SDP Offer/Answer Model [RFC3264], SDP source-specific attributes describe only the sources that each party is
   willing to send (whether it is sending RTP data or RTCP report
   blocks).  No mechanism is provided by which an answer can accept or
   reject individual sources within a media stream; if the set of
   sources in a media stream is unacceptable, the answerer's only option
   is to reject the media stream or the entire multimedia session.


Note that in the example in RFC 4588 Section 8.8 where there is only one source, there are no ssrc-group lines at all:


 v=0 
 o=mascha 2980675221 2980675778 IN IP4 host.example.net 
 c=IN IP4 192.0.2.0 
 m=video 49170 RTP/AVPF 96 97 
 a=rtpmap:96 MP4V-ES/90000 
 a=rtcp-fb:96 nack 
 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F 
 a=rtpmap:97 rtx/90000 
 a=fmtp:97 apt=96;rtx-time=3000

The situation would be the same for FEC groups created via ssrc-group:FEC. From 

      The FEC and the payload MAY also be multiplexed by SSRC into one
      single RTP session, with separate SSRC values, if the association
      between FEC and payload streams are communicated to all members of
      the session.  If SDP is used, this association MAY be communicated
      through the FEC ssrc-group semantic [RFC5576]; other mechanisms
      are also possible.  Receivers MUST NOT attempt to interpret FEC
      streams for which they do not have information to associate them
      with the corresponding payload streams.



On Oct 21, 2014, at 11:36 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

I hope I can rule my SDP logic based on standards rather than on how Chrome implements some features.

My question was generic: if I receive the above SDP, how do I know which payloads each ssrc is supposed to transport?

On 21 Oct 2014 19:57, "Peter Thatcher" <pthatcher@google.com> wrote:
I'm not sure where it's specified, but here's where it's implemented:

https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengine.cc#4108

It only supports 2 SSRCs for a FID group.  It would ignore any more than that.

On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

How is that? Where is that specified? What about if I include 3 ssrc values in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher" <pthatcher@google.com> wrote:
345259865 is "real"
2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=video 62164 RTP/SAVPF 100 116 117 96
a=mid:video
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=ssrc-group:FID 345259865 2693756249
a=ssrc:345259865 cname:erS7E/KHLYKTejNs
a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249 cname:erS7E/KHLYKTejNs
a=ssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.  The "ssrc-group" Media Attribute

   a=ssrc-group:<semantics> <ssrc-id> ...

   [..]

   The <semantics> parameter is taken from the specification of the
   "group" attribute [RFC3388].  The initial semantic values defined for
   the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
   and FEC (Forward Error Correction) [RFC4756].  In each case, the
   relationship among the grouped sources is the same as the
   relationship among corresponding sources in media streams grouped
   using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

   Several "m" lines grouped together using FID semantics form a media
   flow.  A media agent handling a media flow that comprises several "m"
   lines MUST send a copy of the media to every "m" line part of the
   flow as long as the codecs and the direction attribute present in a
   particular "m" line allow it.

   It is assumed that the application uses only one codec at a time to
   encode the media produced.  This codec MAY change dynamically during
   the session, but at any particular moment only one codec is in use.

   The application encodes the media using the current codec and checks
   one by one all the "m" lines that are part of the flow.  If a
   particular "m" line contains the codec being used and the direction
   attribute is "sendonly" or "sendrecv", a copy of the encoded media is
   sent to the address/port specified in that particular media stream.
   If either the "m" line does not contain the codec being used or the
   direction attribute is neither "sendonly" nor "sendrecv", nothing is
   sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?




--
Iñaki Baz Castillo
<ibc@aliax.net>

_______________________________________________
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

--------------070303030708080500070802-- From nobody Wed Oct 22 12:40:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01691AD3C6 for ; Wed, 22 Oct 2014 12:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.412 X-Spam-Level: X-Spam-Status: No, score=0.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ufewnCz7TzQ for ; Wed, 22 Oct 2014 12:40:34 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0819F1AD3C1 for ; Wed, 22 Oct 2014 12:40:33 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so2499630vcb.10 for ; Wed, 22 Oct 2014 12:40:33 -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; bh=uk+RQjZNLTZM53SC5W2HBCkx3O8O9QiHro7hs56kFx0=; b=R49QZ81mqiZPaBVDTuKP+s1fFX6eoZuqGNFtJAlEP71UGB2J/4A3y4jHuX54BVynom +zgXcQRwY0SHcHe/lk35eDw539e3y047xqwrHzJDkW7MBNl3ttOIm1vilMrdI07LPfwQ JBVi27Y0ZQejO+bkv+IzSPEdKgXmYGxlTTBc3JtH69XKuNEynJQc6Tpfy9zmDFbMmU8E PGBc9NPVZXvfVniYRDsMAVH90DG0ZoogwiffGDCQiFb3/WMPDTjcQz7vVwMF0YDEsJFZ spYN9iu5bfsQUm7tlyupeENni42NU32tZc503Cw+G+ThhyxEL0Yhngdv6LomsN7Vhw5N GAEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uk+RQjZNLTZM53SC5W2HBCkx3O8O9QiHro7hs56kFx0=; b=Baa/Xmy5u9Wnzm8VshKf4aaJaveNTNkywb8cH/8lxHLIwnALmrKbVFY194OOJXMF0n xjla7n8kqj1zL21dc12C7MqfJWj2qblYryH9dVusOIW9W7+G95DyjeUfv2zUol7iChj+ K0xBv9qy5/wAtIaFfVul8ICX726lf/28FzylYd1ymAW9s3RHpmsDBwHZ1TypBgVQG3N2 IbLMGPwqqo0z1m5ncrHSpW7crC/HrZDbx7+CQqVIMEMN9Ira2Pm/h69zNdvFAIIob1ps aSohHfphp+xJrrl2awR7XTYdOx3lf+GiqhfOkff55AZY6u0QMFhyn3EHB44L1O7r58yH xEwQ== X-Gm-Message-State: ALoCoQkwFZDiwoR1jW7NkM69Ugz/fFuZZ4PTzrzYOw5ObBkIJ1EF0TvONW6JaT9BI12De9cgKJqe X-Received: by 10.220.1.15 with SMTP id 15mr131363vcd.39.1414006833026; Wed, 22 Oct 2014 12:40:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.173.136 with HTTP; Wed, 22 Oct 2014 12:39:50 -0700 (PDT) In-Reply-To: <544806D1.8010606@gmail.com> References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <5A936EB2-EC94-49BD-AF11-E5A5141D77BE@gmail.com> <544806D1.8010606@gmail.com> From: Peter Thatcher Date: Wed, 22 Oct 2014 12:39:50 -0700 Message-ID: To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=001a11c3cc02fe3a280506081ea8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IFd4OrN9lsoW80Rs407aJyqRgBw Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 19:40:38 -0000 --001a11c3cc02fe3a280506081ea8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Most of the discussion here has been about having enough information to receive packets. But there's another side to it in the rtcweb case. When viewed as an API surface, having SDP that the JS gives to the browser which means "use one of these for RTX, and one for the normal media flow, but you pick which" is suboptimal. As an API surface, it would be much better to allow the application to be explicit about which SSRC it wants for which. On Wed, Oct 22, 2014 at 12:34 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi, > > I disagree, It is not possible just by looking at the SDP to know which > ssrc is from the media and which is from rtx. While for WebRTC-endpoints = it > may be irrelevant because, as you say, you can wait for the RTP data to > check the payload type and match the ssrc, we have seen that it is a must > have for interoperability with ORTC. > > Best regards > Sergio > > On 22/10/2014 21:28, Bernard Aboba wrote: > > I agree. The SSRC-groups are included only to make it clear which > FEC/RED/RTX streams go with which media streams in the multiple source > case. As long as payload types are distinct we have all the information w= e > need. > > On Oct 22, 2014, at 12:16 PM, Suhas Nandakumar > wrote: > > Just thinking loud > As long as there is enough information to unabigously map the incoming > streams to the SDP, i dont see we need any more information to be added. > > I feel the combination of SSRC and Payload Type in the RTP packet is > good enough to find the mapping to the appropriate media line (if the PTs > are not repeated) when needed. > > So in the initial examples above, ssrc-group communicated in SDP along > with semantics (FEC,FID) when applied to incoming SSRCs and the associate= d > payload type has all the needed info for the receiver to demux at the rtp > level as well as map at the SDP level. Thus i dont see a need for > specifying PT association explicitly in SDP for the ssrc-groups. > > Cheers > Suhas > > On Wed, Oct 22, 2014 at 12:01 PM, Bernard Aboba > wrote: > >> SDP specifies payload types for RED/ULPFEC/RTX so as to allow >> differentiation within an ssrc-group. So while an fmtp: attribute could = be >> used to denote a media stream on an a:ssrc line, it is not necessary. >> >> RFC 5176 Example 3 gives an example with two cameras in which there are >> two ssrc-group lines (one for each camera), with payload type used to >> differentiate between H.264 and RTX in each ssrc-group: >> >> >> m=3Dvideo 49174 RTP/AVPF 96 98 >> >> a=3Drtpmap:96 H.264/90000 >> >> a=3Drtpmap:98 rtx/90000 >> >> a=3Dfmtp:98 apt=3D96;rtx-time=3D3000 >> >> a=3Dssrc-group:FID 11111 22222 >> >> a=3Dssrc:11111 cname:user3@example.com >> >> a=3Dssrc:22222 cname:user3@example.com >> >> a=3Dssrc-group:FID 33333 44444 >> >> a=3Dssrc:33333 cname:user3@example.com >> >> a=3Dssrc:44444 cname:user3@example.com >> >> I believe that RFC 5176 includes the two groups to make clear that ther= e are two sources so that the Answerer might choose to reject the m-line if= it cannot handle that. From RFC 5176 Section 8: >> >> When used with the SDP Offer/Answer Model [RFC3264 ], SDP source-specific attributes describe only the sources= that each party is >> willing to send (whether it is sending RTP data or RTCP report >> blocks). No mechanism is provided by which an answer can accept or >> reject individual sources within a media stream; if the set of >> sources in a media stream is unacceptable, the answerer's only option >> is to reject the media stream or the entire multimedia session. >> >> Note that in the example in RFC 4588 Section 8.8 where there is only on= e source, there are no ssrc-group lines at all: >> >> v=3D0 >> >> o=3Dmascha 2980675221 2980675778 IN IP4 host.example.net >> >> c=3DIN IP4 192.0.2.0 >> >> m=3Dvideo 49170 RTP/AVPF 96 97 >> >> a=3Drtpmap:96 MP4V-ES/90000 >> >> a=3Drtcp-fb:96 nack >> >> a=3Dfmtp:96 profile-level-id=3D8;config=3D01010000012000884006682C2090A= 21F >> >> a=3Drtpmap:97 rtx/90000 >> >> a=3Dfmtp:97 apt=3D96;rtx-time=3D3000 >> >> >> The situation would be the same for FEC groups created via >> ssrc-group:FEC. From >> https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux : >> >> The FEC and the payload MAY also be multiplexed by SSRC into one >> single RTP session, with separate SSRC values, if the association >> between FEC and payload streams are communicated to all members of >> the session. If SDP is used, this association MAY be communicated >> through the FEC ssrc-group semantic [RFC5576 ]; other mechanisms >> are also possible. Receivers MUST NOT attempt to interpret FEC >> streams for which they do not have information to associate them >> with the corresponding payload streams. >> >> >> >> >> On Oct 21, 2014, at 11:36 AM, I=C3=B1aki Baz Castillo wr= ote: >> >> I hope I can rule my SDP logic based on standards rather than on how >> Chrome implements some features. >> >> My question was generic: if I receive the above SDP, how do I know which >> payloads each ssrc is supposed to transport? >> On 21 Oct 2014 19:57, "Peter Thatcher" wrote: >> >>> I'm not sure where it's specified, but here's where it's implemented: >>> >>> >>> https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/= webrtcvideoengine.cc#4108 >>> >>> It only supports 2 SSRCs for a FID group. It would ignore any more >>> than that. >>> >>> On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo >>> wrote: >>> >>>> How is that? Where is that specified? What about if I include 3 ssrc >>>> values in the ssrc-group? What is each one for? >>>> On 21 Oct 2014 19:31, "Peter Thatcher" wrote: >>>> >>>>> 345259865 is "real" >>>>> 2693756249 is rtx >>>>> >>>>> On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> May I know which SSRC (345259865 or 2693756249) will be used for the >>>>>> real media stream (plus RED and FEC) and which SSRC will be used for >>>>>> RTX? >>>>>> >>>>>> >>>>>> >>>>>> -------------------------- >>>>>> m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 >>>>>> a=3Dmid:video >>>>>> a=3Drtpmap:100 VP8/90000 >>>>>> a=3Drtpmap:116 red/90000 >>>>>> a=3Drtpmap:117 ulpfec/90000 >>>>>> a=3Drtpmap:96 rtx/90000 >>>>>> a=3Dfmtp:96 apt=3D100 >>>>>> a=3Dssrc-group:FID 345259865 2693756249 >>>>>> a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs >>>>>> a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>>> a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>>> a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>>> a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs >>>>>> a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>>> a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >>>>>> a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >>>>>> ------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> RFC 5576 does not clarify it at all: >>>>>> >>>>>> http://tools.ietf.org/html/rfc5576#section-4.2 >>>>>> >>>>>> -------------------------------------------------- >>>>>> 4.2. The "ssrc-group" Media Attribute >>>>>> >>>>>> a=3Dssrc-group: ... >>>>>> >>>>>> [..] >>>>>> >>>>>> The parameter is taken from the specification of the >>>>>> "group" attribute [RFC3388]. The initial semantic values defined >>>>>> for >>>>>> the "ssrc-group" attribute are FID (Flow Identification) [RFC3388= ] >>>>>> and FEC (Forward Error Correction) [RFC4756]. In each case, the >>>>>> relationship among the grouped sources is the same as the >>>>>> relationship among corresponding sources in media streams grouped >>>>>> using the SDP "group" attribute. >>>>>> -------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> The referenced RFC 3388 neither clarifies it: >>>>>> >>>>>> --------------------------------------------------- >>>>>> 7.4 FID Semantics >>>>>> >>>>>> Several "m" lines grouped together using FID semantics form a med= ia >>>>>> flow. A media agent handling a media flow that comprises several >>>>>> "m" >>>>>> lines MUST send a copy of the media to every "m" line part of the >>>>>> flow as long as the codecs and the direction attribute present in= a >>>>>> particular "m" line allow it. >>>>>> >>>>>> It is assumed that the application uses only one codec at a time = to >>>>>> encode the media produced. This codec MAY change dynamically >>>>>> during >>>>>> the session, but at any particular moment only one codec is in us= e. >>>>>> >>>>>> The application encodes the media using the current codec and >>>>>> checks >>>>>> one by one all the "m" lines that are part of the flow. If a >>>>>> particular "m" line contains the codec being used and the directi= on >>>>>> attribute is "sendonly" or "sendrecv", a copy of the encoded medi= a >>>>>> is >>>>>> sent to the address/port specified in that particular media strea= m. >>>>>> If either the "m" line does not contain the codec being used or t= he >>>>>> direction attribute is neither "sendonly" nor "sendrecv", nothing >>>>>> is >>>>>> sent over this media stream. >>>>>> ---------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> So, how is the usage of ssrc-group? Where is it really defined? >>>>>> >>>>>> Can I put more than 2 ssrc together in the same ssrc-group line? >>>>>> >>>>>> How should the receiver interpret it? >>>>>> >>>>>> Does a ssrc-group always mean RTX usage? Where is that specified in >>>>>> the above SDP? >>>>>> >>>>>> Does not the above SDP look a complete mixture of hacks and >>>>>> workarounds? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> I=C3=B1aki Baz Castillo >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c3cc02fe3a280506081ea8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Most of the discussion here has been about having enoug= h information to receive packets.=C2=A0 But there's another side to it = in the rtcweb case.=C2=A0 When viewed as an API surface, having SDP that th= e JS gives to the browser which means "use one of these for RTX, and o= ne for the normal media flow, but you pick which" is suboptimal.=C2=A0= As an API surface, it would be much better to allow the application to be = explicit about which SSRC it wants for which.

=C2=A0= =C2=A0

On Wed, Oct 22, 2014 at 12:34 PM, Sergio Garcia Murillo = <se= rgio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
Hi,

I disagree, It is not possible just by looking at the SDP to know which ssrc is from the media and which is from rtx. While for WebRTC-endpoints it may be irrelevant because, as you say, you can wait for the RTP data to check the payload type and match the ssrc, we have seen that it is a must have for interoperability with ORTC.

Best regards
Sergio

On 22/10/2014 21:28, Bernard Aboba wrote:
=20
I agree. The SSRC-groups are included only to make it clear which FEC/RED/RTX streams go with which media streams in the multiple source case. As long as payload types are distinct we have all the information we need.

On Oct 22, 2014, at 12:16 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:

Just thinking loud=C2=A0
=C2=A0As long as there is enough information to unabigousl= y map the incoming streams to the SDP, i dont see we need any more information to be added.

I feel the combination of SSRC and Payload Type in the RTP packet is good enough to find the mapping to the appropriate media line (if the PTs are not repeated) when needed.

So in the initial examples above, ssrc-group communicated in SDP along with semantics (FEC,FID) when applied to incoming SSRCs and the associated payload type has all the needed info for the receiver to demux at the rtp level as well as map at the SDP level. Thus i dont see a need for specifying PT association explicitly in SDP for the ssrc-groups.

Cheers
Suhas

On Wed, Oct 22, 2014 at 12:01 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
SDP specifies payload types for RED/ULPFEC/RTX so as to allow differentiation within an ssrc-group. So while an fmtp: attribute could be used to denote a media stream on an a:ssrc line, it is not necessary.

RFC 5176 Example 3 gives an example with two cameras in which there are two ssrc-group lines (one for each camera), with payload type used to differentiate between H.264 and RTX in each ssrc-group:


   m=3Dvideo 49174 RTP/AVPF 96 98=C2=A0
=C2=A0a=3Drtpmap:96 H.264/90000=C2=A0
=C2=A0a=3Drtpmap:98 rtx/90000=C2=A0
=C2=A0a=3Dfmtp:98 apt=3D96;rtx-time=3D3000=C2=A0=

=C2=A0a=3Dssrc-group:FID 11111 22222=C2=A0
=C2=A0a=3Dssrc:11111 cname:user3@example.com=C2=A0
=C2=A0a=3Dssrc:22222 cname:user3@example.com=C2=A0
=C2=A0a=3Dssrc-group:FID 33333 44444=C2=A0
=C2=A0a=3Dssrc:33333 cname:user3@example.com=C2=A0
=C2=A0a=3Dssrc:44444 cname:user3@example.com



I believe that RFC 5176 includes the two groups =
to make clear that there are two sources so that the Answerer might choose =
to reject the m-line if it cannot handle that.=C2=A0From RFC 5176 Section 8:


When used with the SDP Offer/Answer Model [<=
a href=3D"http://tools.ietf.org/html/rfc3264" title=3D""An Offer/Answe=
r Model with Session Description Protocol (SDP)"" style=3D"white-space=
:normal;background-color:rgba(255,255,255,0);font-family:UICTFontTextStyleB=
ody" target=3D"_blank">RFC3264], SDP sou=
rce-specific attributes describe only the sources that each party is
   willing to send (whether it is sending RTP data or RTCP report
   blocks).  No mechanism is provided by which an answer can accept or
   reject individual sources within a media stream; if the set of
   sources in a media stream is unacceptable, the answerer's only optio=
n
   is to reject the media stream or the entire multimedia session.
                    



                    
Note that in the example in RFC 4588 Section 8.8 wh=
ere there is only one source, there are no ssrc-group lines at all:<=
/pre>
                    



                    
=C2=A0v=3D0=C2=A0

                    
=C2=A0o=3Dmascha 2980675221 2980675778 IN IP4 host.example.net=C2=A0=


                    
=C2=A0c=3DIN IP4 192.0.2.0=C2=A0

                    
=C2=A0m=3Dvideo 49170 RTP/AVPF 96 97=C2=A0
                    
=C2=A0a=3Drtpmap:96 MP4V-ES/90000=C2=A0
                    
=C2=A0a=3Drtcp-fb:96 nack=C2=A0

                    
=C2=A0a=3Dfmtp:96 profile-level-id=3D8;config=3D010=
10000012000884006682C2090A21F=C2=A0

                    
=C2=A0a=3Drtpmap:97 rtx/90000=C2=A0

                    
=C2=A0a=3Dfmtp:97 apt=3D96;rtx-time=3D3000

The situation would be the same for FEC groups created via ssrc-group:FEC. From=C2=A0

      The FEC and the payload MAY also be multip=
lexed by SSRC into one
      single RTP session, with separate SSRC values, if the association
      between FEC and payload streams are communicated to all members of
      the session.  If SDP is used, this association MAY be communicated
      through the FEC ssrc-group semantic [RFC5576]; other=
 mechanisms
      are also possible.  Receivers MUST NOT attempt to interpret FEC
      streams for which they do not have information to associate them
      with the corresponding payload streams.



On Oct 21, 2014, at 11:36 AM, I=C3=B1aki Baz Castil= lo <ibc@aliax.net> wrote:

I hope I can rule my SDP logic based on standards rather than on how Chrome implements some features.

My question was generic: if I receive the above SDP, how do I know which payloads each ssrc is supposed to transport?

On 21 Oct 2014 19:57, "Peter Thatcher" <pthatcher@google.com> wrote:
I'm not sure where it's specified, but here's where it's implemented:

https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webr= tc/webrtcvideoengine.cc#4108

It only supports 2 SSRCs for a FID group.=C2=A0 It would ignore any more than that.

On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo= <i= bc@aliax.net> wrote:

How is that? Where is that specified? What about if I include 3 ssrc values in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher" <pthatcher@google.com> wrote:
345259865 is "real"
= 2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo = <ibc@aliax.net>= ; wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000<= br> a=3Drtpmap:116 red/90000<= br> a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000 a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 2693756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bK= VgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn= 5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4a= fd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/h= tml/rfc5576#section-4.2

--------------------------------------------------
4.2.=C2=A0 The "ssrc= -group" Media Attribute

=C2=A0 =C2=A0a=3Dssrc-group:<= semantics> <ssrc-id> ...

=C2=A0 =C2=A0[..]

=C2=A0 =C2=A0The <semantics> parameter is taken from the specification of the
=C2=A0 =C2=A0"group&= quot; attribute [RFC3388].=C2=A0 The initial semantic values defined for
=C2=A0 =C2=A0the "ss= rc-group" attribute are FID (Flow Identification) [RFC3388]
=C2=A0 =C2=A0and FEC (For= ward Error Correction) [RFC4756].=C2=A0 In each case, the
=C2=A0 =C2=A0relationship= among the grouped sources is the same as the
=C2=A0 =C2=A0relationship= among corresponding sources in media streams grouped
=C2=A0 =C2=A0using the SD= P "group" attribu= te.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

=C2=A0 =C2=A0Several &quo= t;m" lines grouped together using FID semantics form a media
=C2=A0 =C2=A0flow.=C2=A0 = A media agent handling a media flow that comprises several "m"
=C2=A0 =C2=A0lines MUST s= end a copy of the media to every "m" line = part of the
=C2=A0 =C2=A0flow as long= as the codecs and the direction attribute present in a
=C2=A0 =C2=A0particular &= quot;m" line allow it.

=C2=A0 =C2=A0It is assume= d that the application uses only one codec at a time to
=C2=A0 =C2=A0encode the m= edia produced.=C2=A0 This code= c MAY change dynamically during
=C2=A0 =C2=A0the session,= but at any particular moment only one codec is in use.

=C2=A0 =C2=A0The applicat= ion encodes the media using the current codec and checks
=C2=A0 =C2=A0one by one a= ll the "m" lines that = are part of the flow.=C2=A0 I= f a
=C2=A0 =C2=A0particular &= quot;m" line contains the codec being used and the direction
=C2=A0 =C2=A0attribute is "sendonly" or "sendrecv", a c= opy of the encoded media is
=C2=A0 =C2=A0sent to the address/port specified in that particular media stream.
=C2=A0 =C2=A0If either th= e "m" line does not contain the codec being used or the
=C2=A0 =C2=A0direction at= tribute is neither "sendonly= " nor "sendrecv", nothing is
=C2=A0 =C2=A0sent over th= is media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?
Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?




--
I=C3=B1aki Baz Castil= lo
<ibc@aliax.net>

_______________________________________________
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/rtcwe= b

_______________________________________________
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


--001a11c3cc02fe3a280506081ea8-- From nobody Wed Oct 22 12:41:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ADA1AD3CC for ; Wed, 22 Oct 2014 12:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIsWdqKKt3-q for ; Wed, 22 Oct 2014 12:41:21 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DF11AD39E for ; Wed, 22 Oct 2014 12:41:21 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so2336663wid.4 for ; Wed, 22 Oct 2014 12:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Kwpqwf2lO0pmIWpZib5YaVKmgp3qFscRA/dN/0/Cj5k=; b=IiK6Uz3am/K5ou2nv41Geu3LSkxhpk00UFhH3bCOuc8ftRWO+wfY94SfHEuEG4gz9E suWeLSn2xtK3Ymzs7ECGqfRSzKe4fbCxAZVVuzZkJLXx8WcvtWv/qxqmf91fYjWpCPdr +GCdNgOD4nB5dptzwzAg6of+BhIKlxgjXt2SKg5jtAIMRHxlR0nqzCtiMq8EBNW2/tV5 2F5RWEWvuNgbG7kZ0CAD5Ixn9q3/ds7yq1kW4WhmPJCalhrdRdNqdKpeHUYb24Gqcmld 1nfNJhdSrQLOjvpINa0rb+3N7OcUI43sfpI8XXeGXKlsZlMJTEBXwV+4j6whaBCUmf/H N+uQ== X-Received: by 10.194.191.233 with SMTP id hb9mr335277wjc.10.1414006879867; Wed, 22 Oct 2014 12:41:19 -0700 (PDT) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id f7sm161120wiz.13.2014.10.22.12.41.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 12:41:19 -0700 (PDT) Message-ID: <54480864.4050106@gmail.com> Date: Wed, 22 Oct 2014 21:41:24 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> In-Reply-To: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> Content-Type: multipart/alternative; boundary="------------040300000407050108030807" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cf2Gxfc6UkbmMq1k6rLrdq-wKuU Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 19:41:25 -0000 This is a multi-part message in MIME format. --------------040300000407050108030807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit BTW, please, please, please, let's use the sssrc-group:FEC and send the FEC in its own ssrc stream, so we don't have to use RED anymore.. On 22/10/2014 21:01, Bernard Aboba wrote: > SDP specifies payload types for RED/ULPFEC/RTX so as to allow > differentiation within an ssrc-group. So while an fmtp: attribute > could be used to denote a media stream on an a:ssrc line, it is not > necessary. > > RFC 5176 Example 3 gives an example with two cameras in which there > are two ssrc-group lines (one for each camera), with payload type used > to differentiate between H.264 and RTX in each ssrc-group: > > > m=video 49174 RTP/AVPF 96 98 > a=rtpmap:96 H.264/90000 > a=rtpmap:98 rtx/90000 > a=fmtp:98 apt=96;rtx-time=3000 > a=ssrc-group:FID 11111 22222 > a=ssrc:11111 cname:user3@example.com > a=ssrc:22222 cname:user3@example.com > a=ssrc-group:FID 33333 44444 > a=ssrc:33333 cname:user3@example.com > a=ssrc:44444 cname:user3@example.com > > I believe that RFC 5176 includes the two groups to make clear that there are two sources so that the Answerer might choose to reject the m-line if it cannot handle that. From RFC 5176 Section 8: > > When used with the SDP Offer/Answer Model [RFC3264 ], SDP source-specific attributes describe only the sources that each party is > willing to send (whether it is sending RTP data or RTCP report > blocks). No mechanism is provided by which an answer can accept or > reject individual sources within a media stream; if the set of > sources in a media stream is unacceptable, the answerer's only option > is to reject the media stream or the entire multimedia session. > > Note that in the example in RFC 4588 Section 8.8 where there is only one source, there are no ssrc-group lines at all: > > v=0 > o=mascha 2980675221 2980675778 IN IP4host.example.net > c=IN IP4 192.0.2.0 > m=video 49170 RTP/AVPF 96 97 > a=rtpmap:96 MP4V-ES/90000 > a=rtcp-fb:96 nack > a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F > a=rtpmap:97 rtx/90000 > a=fmtp:97 apt=96;rtx-time=3000 > > The situation would be the same for FEC groups created via > ssrc-group:FEC. From > https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux : > > The FEC and the payload MAY also be multiplexed by SSRC into one > single RTP session, with separate SSRC values, if the association > between FEC and payload streams are communicated to all members of > the session. If SDP is used, this association MAY be communicated > through the FEC ssrc-group semantic [RFC5576 ]; other mechanisms > are also possible. Receivers MUST NOT attempt to interpret FEC > streams for which they do not have information to associate them > with the corresponding payload streams. > > > > On Oct 21, 2014, at 11:36 AM, Iñaki Baz Castillo > wrote: > >> I hope I can rule my SDP logic based on standards rather than on how >> Chrome implements some features. >> >> My question was generic: if I receive the above SDP, how do I know >> which payloads each ssrc is supposed to transport? >> >> On 21 Oct 2014 19:57, "Peter Thatcher" > > wrote: >> >> I'm not sure where it's specified, but here's where it's implemented: >> >> https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengine.cc#4108 >> >> It only supports 2 SSRCs for a FID group. It would ignore any >> more than that. >> >> On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo >> > wrote: >> >> How is that? Where is that specified? What about if I include >> 3 ssrc values in the ssrc-group? What is each one for? >> >> On 21 Oct 2014 19:31, "Peter Thatcher" > > wrote: >> >> 345259865 is "real" >> 2693756249 is rtx >> >> On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo >> > wrote: >> >> Hi, >> >> May I know which SSRC (345259865 or 2693756249 >> ) will be used for the >> real media stream (plus RED and FEC) and which SSRC >> will be used for >> RTX? >> >> >> >> -------------------------- >> m=video 62164 RTP/SAVPF 100 116 117 96 >> a=mid:video >> a=rtpmap:100 VP8/90000 >> a=rtpmap:116 red/90000 >> a=rtpmap:117 ulpfec/90000 >> a=rtpmap:96 rtx/90000 >> a=fmtp:96 apt=100 >> a=ssrc-group:FID 345259865 2693756249 >> a=ssrc:345259865 cname:erS7E/KHLYKTejNs >> a=ssrc:345259865 >> msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >> c0134f05-e7c2-4afd-a979-4e224de5eb91 >> a=ssrc:345259865 >> mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >> a=ssrc:345259865 >> label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >> a=ssrc:2693756249 cname:erS7E/KHLYKTejNs >> a=ssrc:2693756249 >> msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >> c0134f05-e7c2-4afd-a979-4e224de5eb91 >> a=ssrc:2693756249 >> mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 >> a=ssrc:2693756249 >> label:c0134f05-e7c2-4afd-a979-4e224de5eb91 >> ------------------------------- >> >> >> >> >> RFC 5576 does not clarify it at all: >> >> http://tools.ietf.org/html/rfc5576#section-4.2 >> >> -------------------------------------------------- >> 4.2. The "ssrc-group" Media Attribute >> >> a=ssrc-group: ... >> >> [..] >> >> The parameter is taken from the >> specification of the >> "group" attribute [RFC3388]. The initial semantic >> values defined for >> the "ssrc-group" attribute are FID (Flow >> Identification) [RFC3388] >> and FEC (Forward Error Correction) [RFC4756]. In >> each case, the >> relationship among the grouped sources is the same >> as the >> relationship among corresponding sources in media >> streams grouped >> using the SDP "group" attribute. >> -------------------------------------------------- >> >> >> >> The referenced RFC 3388 neither clarifies it: >> >> --------------------------------------------------- >> 7.4 FID Semantics >> >> Several "m" lines grouped together using FID >> semantics form a media >> flow. A media agent handling a media flow that >> comprises several "m" >> lines MUST send a copy of the media to every "m" >> line part of the >> flow as long as the codecs and the direction >> attribute present in a >> particular "m" line allow it. >> >> It is assumed that the application uses only one >> codec at a time to >> encode the media produced. This codec MAY change >> dynamically during >> the session, but at any particular moment only one >> codec is in use. >> >> The application encodes the media using the >> current codec and checks >> one by one all the "m" lines that are part of the >> flow. If a >> particular "m" line contains the codec being used >> and the direction >> attribute is "sendonly" or "sendrecv", a copy of >> the encoded media is >> sent to the address/port specified in that >> particular media stream. >> If either the "m" line does not contain the codec >> being used or the >> direction attribute is neither "sendonly" nor >> "sendrecv", nothing is >> sent over this media stream. >> ---------------------------------------------------- >> >> >> >> >> So, how is the usage of ssrc-group? Where is it >> really defined? >> >> Can I put more than 2 ssrc together in the same >> ssrc-group line? >> >> How should the receiver interpret it? >> >> Does a ssrc-group always mean RTX usage? Where is >> that specified in >> the above SDP? >> >> Does not the above SDP look a complete mixture of >> hacks and workarounds? >> >> >> >> >> -- >> Iñaki Baz Castillo >> > >> --------------040300000407050108030807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
BTW, please, please, please, let's use  the sssrc-group:FEC and send the FEC in its own ssrc stream, so we don't have to use RED anymore..

On 22/10/2014 21:01, Bernard Aboba wrote:
SDP specifies payload types for RED/ULPFEC/RTX so as to allow differentiation within an ssrc-group. So while an fmtp: attribute could be used to denote a media stream on an a:ssrc line, it is not necessary.

RFC 5176 Example 3 gives an example with two cameras in which there are two ssrc-group lines (one for each camera), with payload type used to differentiate between H.264 and RTX in each ssrc-group:


   m=video 49174 RTP/AVPF 96 98 
 a=rtpmap:96 H.264/90000 
 a=rtpmap:98 rtx/90000 
 a=fmtp:98 apt=96;rtx-time=3000 
 a=ssrc-group:FID 11111 22222 
 a=ssrc:11111 cname:user3@example.com 
 a=ssrc:22222 cname:user3@example.com 
 a=ssrc-group:FID 33333 44444 
 a=ssrc:33333 cname:user3@example.com 
 a=ssrc:44444 cname:user3@example.com



I believe that RFC 5176 includes the two groups to make clear that there are two sources so that the Answerer might choose to reject the m-line if it cannot handle that. From RFC 5176 Section 8:


When used with the SDP Offer/Answer Model [RFC3264], SDP source-specific attributes describe only the sources that each party is
   willing to send (whether it is sending RTP data or RTCP report
   blocks).  No mechanism is provided by which an answer can accept or
   reject individual sources within a media stream; if the set of
   sources in a media stream is unacceptable, the answerer's only option
   is to reject the media stream or the entire multimedia session.


Note that in the example in RFC 4588 Section 8.8 where there is only one source, there are no ssrc-group lines at all:


 v=0 
 o=mascha 2980675221 2980675778 IN IP4 host.example.net 
 c=IN IP4 192.0.2.0 
 m=video 49170 RTP/AVPF 96 97 
 a=rtpmap:96 MP4V-ES/90000 
 a=rtcp-fb:96 nack 
 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F 
 a=rtpmap:97 rtx/90000 
 a=fmtp:97 apt=96;rtx-time=3000

The situation would be the same for FEC groups created via ssrc-group:FEC. From 

      The FEC and the payload MAY also be multiplexed by SSRC into one
      single RTP session, with separate SSRC values, if the association
      between FEC and payload streams are communicated to all members of
      the session.  If SDP is used, this association MAY be communicated
      through the FEC ssrc-group semantic [RFC5576]; other mechanisms
      are also possible.  Receivers MUST NOT attempt to interpret FEC
      streams for which they do not have information to associate them
      with the corresponding payload streams.



On Oct 21, 2014, at 11:36 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

I hope I can rule my SDP logic based on standards rather than on how Chrome implements some features.

My question was generic: if I receive the above SDP, how do I know which payloads each ssrc is supposed to transport?

On 21 Oct 2014 19:57, "Peter Thatcher" <pthatcher@google.com> wrote:
I'm not sure where it's specified, but here's where it's implemented:

https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/webrtcvideoengine.cc#4108

It only supports 2 SSRCs for a FID group.  It would ignore any more than that.

On Tue, Oct 21, 2014 at 10:40 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

How is that? Where is that specified? What about if I include 3 ssrc values in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher" <pthatcher@google.com> wrote:
345259865 is "real"
2693756249 is rtx

On Tue, Oct 21, 2014 at 9:25 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=video 62164 RTP/SAVPF 100 116 117 96
a=mid:video
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=ssrc-group:FID 345259865 2693756249
a=ssrc:345259865 cname:erS7E/KHLYKTejNs
a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249 cname:erS7E/KHLYKTejNs
a=ssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=ssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=ssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.  The "ssrc-group" Media Attribute

   a=ssrc-group:<semantics> <ssrc-id> ...

   [..]

   The <semantics> parameter is taken from the specification of the
   "group" attribute [RFC3388].  The initial semantic values defined for
   the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
   and FEC (Forward Error Correction) [RFC4756].  In each case, the
   relationship among the grouped sources is the same as the
   relationship among corresponding sources in media streams grouped
   using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

   Several "m" lines grouped together using FID semantics form a media
   flow.  A media agent handling a media flow that comprises several "m"
   lines MUST send a copy of the media to every "m" line part of the
   flow as long as the codecs and the direction attribute present in a
   particular "m" line allow it.

   It is assumed that the application uses only one codec at a time to
   encode the media produced.  This codec MAY change dynamically during
   the session, but at any particular moment only one codec is in use.

   The application encodes the media using the current codec and checks
   one by one all the "m" lines that are part of the flow.  If a
   particular "m" line contains the codec being used and the direction
   attribute is "sendonly" or "sendrecv", a copy of the encoded media is
   sent to the address/port specified in that particular media stream.
   If either the "m" line does not contain the codec being used or the
   direction attribute is neither "sendonly" nor "sendrecv", nothing is
   sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?




--
Iñaki Baz Castillo
<ibc@aliax.net>


--------------040300000407050108030807-- From nobody Wed Oct 22 12:46:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DB91AD39E for ; Wed, 22 Oct 2014 12:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGPna7nVIq9w for ; Wed, 22 Oct 2014 12:46:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::751]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFD91AD3E7 for ; Wed, 22 Oct 2014 12:46:05 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB361.namprd07.prod.outlook.com (10.141.75.19) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 22 Oct 2014 19:45:41 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.72]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.72]) with mapi id 15.00.1049.012; Wed, 22 Oct 2014 19:45:41 +0000 From: Stephan Wenger To: Stephan Wenger , Watson Ladd , Alexandre GOUAILLARD Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHOrixjgMwfvYrSbUqrcWE5foJ0c5wzqjdjgAAvKoCAAddnAIAAAwiAgAAJmQCAAQDrgIACFIiAgAEvmwCAAAgMAIAACFqAgAAAiICAACAFgIAEXFwA Date: Wed, 22 Oct 2014 19:45:40 +0000 Message-ID: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR07MB361; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(479174003)(189002)(24454002)(86362001)(87936001)(4396001)(15202345003)(2656002)(122556002)(21056001)(15975445006)(76176999)(92566001)(85852003)(50986999)(101416001)(92726001)(93886004)(16601075003)(54356999)(85306004)(97736003)(77096002)(120916001)(99396003)(76482002)(20776003)(64706001)(107046002)(40100003)(66066001)(46102003)(36756003)(31966008)(19580395003)(19580405001)(95666004)(106116001)(99286002)(105586002)(80022003)(106356001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR07MB361; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/p18W3QTx45Mv2L_K4V37Yl-L9-I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 19:46:09 -0000 SGksDQpJIGhhdmUgdG8gbWFrZSBvbmUgY29ycmVjdGlvbiBpbiB0aGUgbGlnaHQgb2YgaW5mb3Jt YXRpb24gdGhhdCBoYXMNCnN1cmZhY2VkIGF0IHRoZSBNUEVHIG1lZXRpbmcgY3VycmVudGx5IG9u Z29pbmcgaW4gU3RyYXNib3VyZy4gIChJoa9tIG5vdCBhdA0KdGhhdCBtZWV0aW5nIHRoaXMgdGlt ZSwgYnV0IGEgY29sbGVhZ3VlIGlzIGFuZCBzaGUgYnJpZWZlZCBtZS4pDQpOb2tpYSBoYXMgbWFk ZSBNUEVHIGFuZCBJU08vSUVDIG9mZmljaWFsbHkgYXdhcmUgdGhhdCB0aGV5IGFyZSBub3Qgd2ls bGluZw0KdG8gbGljZW5zZSBlc3NlbnRpYWwgcGF0ZW50cyB1bmRlciBSQU5EIHRlcm1zLiAgRm9y IHRob3NlIHdpdGggTVBFRw0KZG9jdW1lbnQgYWNjZXNzLCBwbGVhc2Ugc2VlIE0zNDkxNy4gIFRo ZSBvZmZpY2lhbCBkZWNsYXJhdGlvbiBpcyBkYXRlZA0KOS8xOS8yMDE0LCBhbmQgaXMgbm90IHll dCBhdmFpbGFibGUgZnJvbSB0aGUgcmVzcGVjdGl2ZSBkYXRhYmFzZXMsIGFzIElTTw0KaXMgYXBw YXJlbnRseSBjaGFuZ2luZyBpdHMgcmVjb3JkYXRpb24gaW5mcmFzdHJ1Y3R1cmUuDQpNeSB1bmRl cnN0YW5kaW5nIG9mIHRoZSBqb2ludCBJVFUvSVNPL0lFQyBwYXRlbnQgcG9saWN5IGlzIHRoYXQg bm8NCnN0YW5kYXJkIGNhbiBiZSBpc3N1ZWQgdGhhdCBoYXMgYSB0eXBlIDMgZGVjbGFyYXRpb24g YWdhaW5zdCBpdC4gIFRvIHRoZQ0KYmVzdCBvZiBteSBrbm93bGVkZ2UsIElTTyBoYXMgbm8gZXN0 YWJsaXNoZWQgcHJvY2VkdXJlIGhvdyB0byBkZWFsIHdpdGgNCnR5cGUgMyAobm9uLVJBTkQpIGRl Y2xhcmF0aW9ucyBhbmQgc3RpbGwga2VlcCB0aGUgc3RhbmRhcmQgcHJvamVjdCBnb2luZy4NClVu bGlrZSwgZm9yIGV4YW1wbGUsIFczQyBhbmQgaXRzIFBhdGVudCBBZHZpc29yeSBHcm91cHMuDQpU aGUgZGVjbGFyYXRpb24gZG9lcyBub3QgbGlzdCBzcGVjaWZpYyBwYXRlbnRzLiBUbyB0aGUgYmVz dCBvZiBteQ0Ka25vd2xlZGdlLCBzdWNoIGluZm8gaXMgbm90IHJlcXVpcmVkIChvbmx5IGRlc2ly ZWQpIGZvciBJU08gYW5kIElFQw0Kc3RhbmRhcmRpemF0aW9uIHdvcmstLW9uZSBvZiB0aGUgZmV3 IGRpZmZlcmVuY2VzIGluIHBhdGVudCBwb2xpY3kNCmd1aWRlbGluZXMgYmV0d2VlbiBJVFUgYW5k IElTTy9JRUMuDQpUaGVyZWZvcmUsIEkgaGF2ZSB0byByb3cgYmFjayBvbiBteSBwcmV2aW91cyBz dGF0ZW1lbnQgb2YgbGlrZWxpbmVzcyBvZg0KaGF2aW5nIGFuIElTTyBudW1iZXIgZm9yIFZQOCBh bnl0aW1lIHNvb24uICBBdCB0aGlzIHBvaW50LCBJIGp1c3QgZG9uoa90DQprbm93IHdoZXRoZXIs IGlmIGV2ZXIsIHRoYXQgd2lsbCBoYXBwZW4uDQpSZWdhcmRzLA0KU3RlcGhhbg0KDQoNCk9uIDEw LzE5LzE0LCA2OjEwIFBNLCAiU3RlcGhhbiBXZW5nZXIiIDxzdGV3ZUBzdGV3ZS5vcmc+IHdyb3Rl Og0KDQo+SGksDQo+DQo+T24gMTAvMTkvMTQsIDk6MTUgQU0sICJXYXRzb24gTGFkZCIgPHdhdHNv bmJsYWRkQGdtYWlsLmNvbT4gd3JvdGU6DQo+DQo+Pk9uIFN1biwgT2N0IDE5LCAyMDE0IGF0IDk6 MTMgQU0sIEFsZXhhbmRyZSBHT1VBSUxMQVJEDQo+PjxhZ291YWlsbGFyZEBnbWFpbC5jb20+IHdy b3RlOg0KPj4+IEBqb25hdGhhbiwNCj4+Pg0KPj4+IHdoaWxlIHlvdSBhcmUgcmlnaHQgYW5kIGF2 YWlsYWJpbGl0eSBvZiAyNjQgaW1wbGVtZW50YXRpb24gb3IgaGFyZHdhcmUNCj4+PiBhY2NlbGVy YXRpb24gaGFzIGltcHJvdmVkLCBpdCBoYXMgbmV2ZXIgYmVlbiByZXBvcnRlZCBhcyBhIHByb2Js ZW0gaW4NCj4+PnRoZQ0KPj4+IHByZXZpb3VzIHBvb2wgYnkgYW55b25lLiBUaGUgMjY0IHJveWFs dGllcywgYW5kIHRoZSBWUDggSVAgcmlza3Mgd2VyZSwNCj4+PiBBRkFJUiwgdGhlIG1haW4gcmVh c29ucyB1c2VkIGJ5IGluZGl2aWR1YWxzIHRvIGp1c3RpZnkgdGhlaXIgcG9zaXRpb25zLg0KPj4+ IFRvZGF5LCBub3RoaW5nIGhhcyBjaGFuZ2VkIHdpdGggcmVzcGVjdCB0byB0aG9zZSB0d28gaXRl bXMgKGV2ZW4gdGhvdWdoDQo+Pj4gcHJvdmlkaW5nIG9wZW4yNjQgcm95YWx0aWVzIGFuZCBhYnNv cmJpbmcgdGhlIGxpY2Vuc2UgY29zdCBmb3Igc29tZQ0KPj4+IHBsYXRmb3JtcyBtaWdodCBoYXZl IGJlZW4gYSBzZXQgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbikuIFRoaXMgaXMgd2h5IEkNCj4+PnRo aW5rDQo+Pj4gdGhlIGNvbmRpdGlvbnMgYXJlIG5vdCBtZXQgZm9yIGEgY29uc2Vuc3VzIHRvIGJl IHJlYWNoZWQuDQo+Pg0KPj5CdXQgbm93IFZQOCBpcyBnb2luZyB0aHJvdWdoIElTTywNCj4NCj4u Li4gYW5kIGlzIGlzIERJUyBiYWxsb3QuICBGZXcgcHJvamVjdHMgaW4gSVNPIGdldCBzdG9wcGVk IGF0IHRoYXQgc3RhZ2UuDQo+VG8gbWUsIGl0qfZzIHByZXR0eSBjbGVhciB0aGF0IFZQOCB3aWxs IGhhdmUgYW4gSVNPL0lFQyBibGVzc2luZyB3aXRoaW4gYQ0KPnllYXIgb3IgdHdvLiAgV2l0aG91 dCBzdWJzdGFudGlhbCB0ZWNobmljYWwgY2hhbmdlcy4gIEdpdmVuIHRoZSB2ZXJ5DQo+bGltaXRl ZCBwYXJ0aWNpcGF0aW9uIGluIHRoZSByZWxldmFudCBzdWJncm91cCBpbiBNUEVHLCBpdKn2cyB1 bmNsZWFyIHRvIG1lDQo+d2hhdCBnb29kIHRoYXQgd2lsbCBkbywgdGhvdWdoLg0KPg0KPj5hbmQg dGhlIHBlb3BsZSBjbGFpbWluZyBwYXRlbnRzIG9uDQo+PlZQOCBoYXZlIGhhZCB0aW1lIHRvIHN1 ZSwgYW5kIGhhdmVuJ3QuDQo+DQo+VGhhdKn2cyBmYWN0dWFsbHkgaW5jb3JyZWN0LiAgVG8gdGhl IGJlc3Qgb2YgbXkga25vd2xlZGdlLCB3aGF0IHdvdWxkIGJlDQo+ZmFjdHVhbGx5IGNvcnJlY3Qg aXMgdGhpczogaW4gdHdvIGNhc2VzLCBjb21wYW5pZXMgaGF2ZSBiZWVuIHN1ZWQgb3Zlcg0KPnBh dGVudHMgYWxsZWdlZGx5IHJlYWRpbmcgb24gVlA4IGluIHRoZSBjb250ZXh0IG9mIHRoZSB3aWRl ciCp+HNtYXJ0cGhvbmUNCj53YXJzqfcgbGF3c3VpdHMsIGFuZCB0aGUgZGVmZW5kYW50cyBoYXZl IHdvbiBub24taW5mcmluZ2VtZW50IHJ1bGluZ3MgaW4NCj50aGUgZmlyc3QgaW5zdGFuY2UgKHRo b3VnaCwgbGFzdCBJIGxvb2tlZCwgYXBwZWFscyB3ZXJlIHBlbmRpbmcgaW4gYm90aA0KPmNhc2Vz KS4gIEF0IGxlYXN0IG9uZSBvdGhlciBjYXNlIHdhcyBzZXR0bGVkIG9uIHVuZGlzY2xvc2VkIHRl cm1zLiAgU29tZQ0KPm9mIHRoZXNlIGNhc2VzIHdlcmUgd2lkZWx5IHJlcG9ydGVkIGluIHRoZSBw cmVzcywgb3RoZXJzIGFyZSBhIGxpdHRsZSBiaXQNCj5oYXJkZXIgdG8gZmluZCB3aXRob3V0IGFj Y2VzcyB0byBsZWdhbCBzZWFyY2ggdG9vbHMuDQo+DQo+PlRoYXQncyBldmlkZW5jZSB0aGF0IHNv bWUNCj4+Y29uY2VybnMgYXJlIG92ZXJibG93bi4NCj4NCj5BbmQgdGhhdCBkZXBlbmRzIG9uIHlv dXIgdmlld3BvaW50Lg0KPg0KPlN0ZXBoYW4NCj4NCj4+DQo+Pj4NCj4+PiBBbGV4Lg0KPj4+DQo+ Pj4NCj4+PiBPbiBTdW4sIE9jdCAxOSwgMjAxNCBhdCAxMTo0MyBQTSwgQmVybmFyZCBBYm9iYQ0K Pj4+PGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPg0KPj4+IHdyb3RlOg0KPj4+Pg0KPj4+PiAiQW5k IGl0cyBvbmUgb2YgdGhlIGlzc3VlcyBob2xkaW5nIHVwIHdpZGVyIGFkb3B0aW9uIG9mIHRoZQ0K Pj4+PnRlY2hub2xvZ3kiDQo+Pj4+DQo+Pj4+IFtCQV0gU3BlY2lmeWluZyBhbiBNVEkgZW5jb2Rl ci9kZWNvZGVyIGlzIG5vdCBzdWZmaWNpZW50IGZvcg0KPj4+PiBpbnRlcm9wZXJhYmlsaXR5LiAg SXQgaXMgYWxzbyBuZWNlc3NhcnkgdG8gc3BlY2lmeSB0aGUgdHJhbnNwb3J0IGluDQo+Pj4+ZW5v dWdoDQo+Pj4+IGRldGFpbCB0byBhbGxvdyBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgdGhh dCBpbnRlcm9wZXJhdGUgd2VsbA0KPj4+PmVub3VnaCB0bw0KPj4+PiBiZSB1c2FibGUgaW4gYSB3 aWRlIHZhcmlldHkgb2Ygc2NlbmFyaW9zLCBpbmNsdWRpbmcgd2lyZWxlc3MgbmV0d29ya3MNCj4+ Pj53aGVyZQ0KPj4+PiBsb3NzIGlzIGNvbW1vbmx5IGV4cGVyaWVuY2VkLg0KPj4+Pg0KPj4+PiBX ZSBtYWRlIHRoZSBtaXN0YWtlIG9mIGhhdmluZyBhbiBNVEkgZGlzY3Vzc2lvbiBwcmV2aW91c2x5 IHdpdGggbm90DQo+Pj4+ZW5vdWdoDQo+Pj4+IGRldGFpbHMgb24gdGhhdCBzdWJqZWN0LCBwYXJ0 aWN1bGFybHkgd2l0aCByZXNwZWN0IHRvIEguMjY0Lg0KPj4+PiBkcmFmdC1pZXRmLXJ0Y3dlYi12 aWRlbyBzZWN0aW9ucyA0LjIgLSA0LjQgcmVtYWluIHNrZXRjaHkgYXQgYmVzdC4NCj4+Pj4NCj4+ Pj4gU28gaWYgd2UgYXJlIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24gYWdhaW4sIGl0IHNob3VsZCBv Y2N1ciBpbiB0aGUNCj4+Pj5jb250ZXh0DQo+Pj4+IG9mIGRldGFpbGVkIHNwZWNpZmljYXRpb25z IGFuZCBpbnRlcm9wZXJhYmlsaXR5IHJlcG9ydHMuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+ Pj4+DQo+Pj4+IE9uIFN1biwgT2N0IDE5LCAyMDE0IGF0IDg6MTQgQU0sIEpvbmF0aGFuIFJvc2Vu YmVyZw0KPj4+PjxqZHJvc2VuQGpkcm9zZW4ubmV0Pg0KPj4+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+ PiBJJ20gaW4gZmF2b3Igb2YgdGFraW5nIGFub3RoZXIgcnVuIGF0IHRoaXMuDQo+Pj4+Pg0KPj4+ Pj4gVGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHJlcGVhdGVkbHkgc2FpZCB0aGF0IGFuIE1USSBjb2Rl YyBpcyBzb21ldGhpbmcNCj4+Pj4+d2UNCj4+Pj4+IG5lZWQgdG8gcHJvZHVjZS4gQW5kIGl0cyBv bmUgb2YgdGhlIGlzc3VlcyBob2xkaW5nIHVwIHdpZGVyIGFkb3B0aW9uDQo+Pj4+Pm9mIHRoZQ0K Pj4+Pj4gdGVjaG5vbG9neSAobm90IHRoZSBvbmx5IG9uZSBmb3Igc3VyZSkuDQo+Pj4+Pg0KPj4+ Pj4gQW5kIHRoaW5ncyBoYXZlIGNoYW5nZWQgc2luY2UgdGhlIGxhc3QgbWVldGluZywgYSB5ZWFy IGFnbyBub3cNCj4+Pj4+KE5vdmVtYmVyDQo+Pj4+PiBpbiBWYW5jb3V2ZXIpLiBDaXNjbydzIG9w ZW4yNjQgcGx1Z2luIHNoaXBwZWQgYW5kIG5vdyBqdXN0IHJlY2VudGx5DQo+Pj4+PmlzDQo+Pj4+ PiBpbnRlZ3JhdGVkIGludG8gRmlyZWZveC4gaU9TOCBzaGlwcGVkIHdpdGggQVBJcyBmb3IgSDI2 NC4gVGhlcmUgYXJlDQo+Pj4+Pm90aGVyDQo+Pj4+PiB0aGluZ3Mgd29ydGggbm90aW5nLiBXaWxs IHRoaXMgY2hhbmdlIHRoZSBtaW5kcyBvZiBldmVyeW9uZT8gU3VyZWx5DQo+Pj4+Pm5vdC4NCj4+ Pj4+IFdpbGwgaXQgc3dheSBlbm91Z2ggZm9yIHVzIHRvIGFjaGlldmUgcm91Z2ggY29uc2Vuc3Vz PyBNYXliZS4gSU1ITyAtDQo+Pj4+PndvcnRoDQo+Pj4+PiBmaW5kaW5nIG91dC4NCj4+Pj4+DQo+ Pj4+PiBPbiBTYXQsIE9jdCAxOCwgMjAxNCBhdCA1OjA4IFBNLCBBbGV4YW5kcmUgR09VQUlMTEFS RA0KPj4+Pj4gPGFnb3VhaWxsYXJkQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiAr MSB0byBub3QgaGF2aW5nIE1USSBjb2RlYyBkaXNjdXNzaW9uIHVubGVzcyBzb21lIHByb2dyZXNz IGhhcyBiZWVuDQo+Pj4+Pj5tYWRlDQo+Pj4+Pj4gb24gVlA4IGF0IE1QRUcuIEFueSBuZXdzIG9u IHRoYXQ/IEknbSBzaGFyaW5nIGhhcmFsZCdzICBmZWVsaW5nIHRoYXQNCj4+Pj4+PnRoZXJlDQo+ Pj4+Pj4gd2FzIG5vIGNoYW5nZSBvbiB0aGUgbWVtYmVycyBwb3NpdGlvbi4NCj4+Pj4+Pg0KPj4+ Pj4+IE9uIEZyaSwgT2N0IDE3LCAyMDE0IGF0IDk6MjIgUE0sIEhhcmFsZCBBbHZlc3RyYW5kDQo+ Pj4+Pj4gPGhhcmFsZEBhbHZlc3RyYW5kLm5vPiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24g MTAvMTcvMjAxNCAxMjowMiBBTSwgQmVybmFyZCBBYm9iYSB3cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiBPbmUgdGhpbmcgd2UgY291bGQgZG8gaW5zdGVhZCBvZiB3YXN0aW5nIHRpbWUgb24gTVRJ IGlzIHRvDQo+Pj4+Pj4+PmFjdHVhbGx5DQo+Pj4+Pj4+PiBtYWtlIHByb2dyZXNzIG9uIFNlY3Rp b25zIDQuMiAtIDQuNCBvZiBkcmFmdC1JRVRGLVJUQ1dFQi12aWRlbywgc28NCj4+Pj4+Pj4+d2Ug Y291bGQNCj4+Pj4+Pj4+IGFjdHVhbGx5IGludGVyb3BlcmF0ZSByZWdhcmRsZXNzIG9mIHRoZSBj b2RlYy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhlIGJpZyBhcmd1bWVudCBmb3IgYW4g TVRJIGlzIGFjdHVhbGx5IHRoZSBvbmUgc3RhdGVkIGluDQo+Pj4+Pj4+LW92ZXJ2aWV3OiBJdA0K Pj4+Pj4+PiBndWFyZHMgYWdhaW5zdCBpbnRlcm9wZXJhYmlsaXR5IGZhaWx1cmUuDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IEkgd291bGQgbGlrZSB0byBoYXZlIGFuIGVjb3N5c3RlbSB3aGVyZSBvbmUgY2Fu IGZpZWxkIGEgYm94LA0KPj4+Pj4+PmNvbm5lY3QgaXQNCj4+Pj4+Pj4gdG8gZXZlcnl0aGluZyBl bHNlLCBhbmQgcnVuIHdlbGwgZm9yICpzb21lKiBsZXZlbCBvZiAid2VsbCIgLSBhbmQgSQ0KPj4+ Pj4+PndvdWxkDQo+Pj4+Pj4+IHByZWZlciB0aGF0IGVjb3N5c3RlbSB0byBiZSBvbmUgd2hlcmUg aXQncyBwb3NzaWJsZSB0byBmaWVsZCB0aGUNCj4+Pj4+Pj5ib3ggd2l0aG91dA0KPj4+Pj4+PiBt YWtpbmcgcHJpb3IgYXJyYW5nZW1lbnRzIHdpdGggYW55b25lIGFib3V0IGxpY2Vuc2VzLg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBUaGlzIGFyZ3VtZW50IGhhc24ndCBjaGFuZ2VkIG9uZSB3aGl0IHNpbmNl IGxhc3QgdGltZSB3ZSBkaXNjdXNzZWQNCj4+Pj4+Pj5pdC4NCj4+Pj4+Pj4gQW5kIEkgZG9uJ3Qg c2VlIG11Y2ggbW92ZW1lbnQgb24gdGhlIHNwZWNpZmljcyBvZiB0aGUgcHJvcG9zYWxzDQo+Pj4+ Pj4+ZWl0aGVyLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBXZSdsbCBoYXZlIHRvIGludGVyb3BlcmF0ZSB3 ZWxsIHdpdGggdGhlIGNvZGVjcyB3ZSBmaWVsZC4gU28gdXNpbmcNCj4+Pj4+Pj5zb21lDQo+Pj4+ Pj4+IHRpbWUgdG8gZGlzY3VzcyBkcmFmdC1pZXRmLXJ0Y3dlYi12aWRlbyBzZWVtcyB0byBtYWtl IHNlbnNlLiAoQW5kDQo+Pj4+Pj4+NC4xIGlzbid0DQo+Pj4+Pj4+IGZpbmlzaGVkIGVpdGhlci4g VGhlcmUncyBvbmUgc2VudGVuY2UgdGhhdCBuZWVkcyB0byBiZSByZW1vdmVkLikNCj4+Pj4+Pj4N Cj4+Pj4+Pj4gSSB3b3VsZG4ndCBzYXkgSSdkIGJlIGhhcHB5IHRvIG5vdCBkaXNjdXNzIHRoaXMg aW4gSG9ub2x1bHUuIEJ1dA0KPj4+Pj4+PkknZA0KPj4+Pj4+PiBwcmVmZXIgdG8gcmUtZGlzY3Vz cyBiYXNlZCBvbiB0aGUga25vd2xlZGdlIHRoYXQgc29tZSBzaWduaWZpY2FudA0KPj4+Pj4+PnBs YXllcnMNCj4+Pj4+Pj4gaGF2ZSBhY3R1YWxseSBjaGFuZ2VkIHRoZWlyIG1pbmRzLg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBBdCB0aGUgbW9tZW50LCBJIGRvbid0IHNlZSBzaWducyB0aGF0IGFueSBvZiB0 aGUgcG9sbCByZXNwb25kZW50cw0KPj4+Pj4+PmhhdmUNCj4+Pj4+Pj4gc2FpZCAiSSBoYXZlIGNo YW5nZWQgbXkgbWluZCIuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhhcmFsZA0KPj4+Pj4+Pg0KPj4+Pj4+ Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIE9j dCAxNiwgMjAxNCwgYXQgMjoyOCBQTSwgTWFydGluIFRob21zb24NCj4+Pj4+Pj4+PiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBPbiAxNiBP Y3RvYmVyIDIwMTQgMTQ6MTcsIE1hdHRoZXcgS2F1Zm1hbiA8bWF0dGhld0BtYXR0aGV3LmF0Pg0K Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4gQW5kIHRoYXQncyBiZWNhdXNlIHNvbWV0aGlu ZyBzdWJzdGFudGl2ZSBoYXMgY2hhbmdlZCwgb3Igc2ltcGx5DQo+Pj4+Pj4+Pj4+IGJlY2F1c2UN Cj4+Pj4+Pj4+Pj4gd2FzdGluZyB0aGUgV0cgdGltZSBvbiB0aGlzIGFnYWluIGlzIG1vcmUgZW50 ZXJ0YWluaW5nIHRoYW4NCj4+Pj4+Pj4+Pj5hY3R1YWxseQ0KPj4+Pj4+Pj4+PiBmaW5pc2hpbmcg YSBzcGVjaWZpY2F0aW9uIHRoYXQgY2FuIGJlIGluZGVwZW5kZW50bHkgaW1wbGVtZW50ZWQNCj4+ Pj4+Pj4+Pj5ieQ0KPj4+Pj4+Pj4+PiBhbGwNCj4+Pj4+Pj4+Pj4gYnJvd3NlciB2ZW5kb3JzPyAo QSBzcGVjaWZpY2F0aW9uIHRoYXQgd2UgYXJlIG5vd2hlcmUgbmVhcg0KPj4+Pj4+Pj4+Pmhhdmlu ZywNCj4+Pj4+Pj4+Pj4gYXMgZmFyIGFzDQo+Pj4+Pj4+Pj4+IEkgY2FuIHRlbGwpDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBQZXJzb25hbGx5LCBJJ3ZlIGZvdW5kIHRoZSByZXByaWV2ZSBmcm9tIHRo aXMgZmlnaHQgcmVmcmVzaGluZy4NCj4+Pj4+Pj4+PkFuZA0KPj4+Pj4+Pj4+IGl0IHdvdWxkIGFw cGVhciB0aGF0IHdlJ3ZlIG1hZGUgc29tZSByZWFsIHByb2dyZXNzIGFzIGEgcmVzdWx0Lg0KPj4+ Pj4+Pj4+SSdkDQo+Pj4+Pj4+Pj4gc3VnZ2VzdCB0aGF0IGlmIHdlIGRvbid0IGhhdmUgbmV3IGlu Zm9ybWF0aW9uLCB3ZSBjb250aW51ZSB0bw0KPj4+Pj4+Pj4+c3BlbmQNCj4+Pj4+Pj4+PiBvdXIg dGltZSBwcm9kdWN0aXZlbHkuICBJZiB3ZSBjYW4ndCBmaW5kIHRvcGljcyB0byBvY2N1cHkgb3Vy DQo+Pj4+Pj4+Pj5tZWV0aW5nDQo+Pj4+Pj4+Pj4gYWdlbmRhIHRpbWUsIHRoZW4gbWF5YmUgd2Ug Y2FuIGZyZWUgYW4gYWdlbmRhIHNsb3QuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IHJ0Y3dlYiBt YWlsaW5nIGxpc3QNCj4+Pj4+Pj4+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+ PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+Pj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+Pj4+Pj4+DQo+ Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+Pj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gcnRjd2ViQGlldGYu b3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAtLQ0KPj4+Pj4+IEFsZXgu IEdvdWFpbGxhcmQsIFBoRCwgUGhELCBNQkENCj4+Pj4+Pg0KPj4+Pj4+IA0KPj4+Pj4+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+Pj4+Pj4tDQo+Pj4+Pj4tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+IENUTyAtIFRlbWFz eXMgQ29tbXVuaWNhdGlvbnMsIFMncG9yZSAvIE1vdW50YWluIFZpZXcNCj4+Pj4+PiBQcmVzaWRl bnQgLSBDb1NNbyBTb2Z0d2FyZSwgQ2FtYnJpZGdlLCBNQQ0KPj4+Pj4+DQo+Pj4+Pj4gDQo+Pj4+ Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pi0NCj4+Pj4+Pi0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4gc2cu bGlua2VkaW4uY29tL2Fnb3VhaWxsYXJkDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBy dGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gcnRjd2ViQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj4gLS0NCj4+Pj4+IEpvbmF0aGFuIFJvc2VuYmVyZywgUGguRC4NCj4+ Pj4+IGpkcm9zZW5AamRyb3Nlbi5uZXQNCj4+Pj4+IGh0dHA6Ly93d3cuamRyb3Nlbi5uZXQNCj4+ Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPj4+Pj4gcnRjd2ViQGlldGYub3JnDQo+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4+Pj4NCj4+ Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAtLQ0KPj4+IEFsZXguIEdvdWFpbGxhcmQsIFBoRCwgUGhE LCBNQkENCj4+PiANCj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+LQ0KPj4+LS0tLS0tLS0tLS0NCj4+ PiBDVE8gLSBUZW1hc3lzIENvbW11bmljYXRpb25zLCBTJ3BvcmUgLyBNb3VudGFpbiBWaWV3DQo+ Pj4gUHJlc2lkZW50IC0gQ29TTW8gU29mdHdhcmUsIENhbWJyaWRnZSwgTUENCj4+PiANCj4+Pi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4+LQ0KPj4+LS0tLS0tLS0tLS0NCj4+PiBzZy5saW5rZWRpbi5jb20v YWdvdWFpbGxhcmQNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+PiBydGN3 ZWJAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYg0KPj4+DQo+Pg0KPj4NCj4+DQo+Pi0tIA0KPj4iVGhvc2Ugd2hvIHdvdWxkIGdpdmUgdXAg RXNzZW50aWFsIExpYmVydHkgdG8gcHVyY2hhc2UgYSBsaXR0bGUNCj4+VGVtcG9yYXJ5IFNhZmV0 eSBkZXNlcnZlIG5laXRoZXIgIExpYmVydHkgbm9yIFNhZmV0eS4iDQo+Pi0tIEJlbmphbWluIEZy YW5rbGluDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj5ydGN3ZWIgbWFpbGluZyBsaXN0DQo+PnJ0Y3dlYkBpZXRmLm9yZw0KPj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+cnRjd2ViIG1haWxpbmcgbGlzdA0K PnJ0Y3dlYkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViDQoNCg== From nobody Wed Oct 22 13:05:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC6D1A1A0A for ; Wed, 22 Oct 2014 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIZBCgtHo3eS for ; Wed, 22 Oct 2014 13:05:39 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6BB1A1A1E for ; Wed, 22 Oct 2014 13:05:38 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 6F4B0AD543762; Wed, 22 Oct 2014 20:05:34 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9MK5YKs002710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 16:05:34 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 16:05:34 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Suhas Nandakumar , Bernard Aboba Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw8eqhMgABHJ4D//8kqMA== Date: Wed, 22 Oct 2014 20:05:33 +0000 Message-ID: References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5EC923US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ViZfl6BvHKfPoJsCcAOwPluD7Lw Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 20:05:42 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5EC923US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpKdXN0IHRoaW5raW5nIGxvdWQNCiBBcyBsb25nIGFzIHRoZXJlIGlzIGVub3VnaCBpbmZvcm1h dGlvbiB0byB1bmFiaWdvdXNseSBtYXAgdGhlIGluY29taW5nIHN0cmVhbXMgdG8gdGhlIFNEUCwg aSBkb250IHNlZSB3ZSBuZWVkIGFueSBtb3JlIGluZm9ybWF0aW9uIHRvIGJlIGFkZGVkLg0KDQpJ IGZlZWwgdGhlIGNvbWJpbmF0aW9uIG9mIFNTUkMgYW5kIFBheWxvYWQgVHlwZSBpbiB0aGUgUlRQ IHBhY2tldCBpcyBnb29kIGVub3VnaCB0byBmaW5kIHRoZSBtYXBwaW5nIHRvIHRoZSBhcHByb3By aWF0ZSBtZWRpYSBsaW5lIChpZiB0aGUgUFRzIGFyZSBub3QgcmVwZWF0ZWQpIHdoZW4gbmVlZGVk Lg0KDQpTbyBpbiB0aGUgaW5pdGlhbCBleGFtcGxlcyBhYm92ZSwgc3NyYy1ncm91cCBjb21tdW5p Y2F0ZWQgaW4gU0RQIGFsb25nIHdpdGggc2VtYW50aWNzIChGRUMsRklEKSB3aGVuIGFwcGxpZWQg dG8gaW5jb21pbmcgU1NSQ3MgYW5kIHRoZSBhc3NvY2lhdGVkIHBheWxvYWQgdHlwZSBoYXMgYWxs IHRoZSBuZWVkZWQgaW5mbyBmb3IgdGhlIHJlY2VpdmVyIHRvIGRlbXV4IGF0IHRoZSBydHAgbGV2 ZWwgYXMgd2VsbCBhcyBtYXAgYXQgdGhlIFNEUCBsZXZlbC4gVGh1cyBpIGRvbnQgc2VlIGEgbmVl ZCBmb3Igc3BlY2lmeWluZyBQVCBhc3NvY2lhdGlvbiBleHBsaWNpdGx5IGluIFNEUCBmb3IgdGhl IHNzcmMtZ3JvdXBzLg0KPFJhanU+DQpGb3IgYSBzaW1wbGUgU0RQIG9mZmVyL2Fuc3dlciBjYXNl IGl0IGlzIHByb2JhYmx5IG5vdCBuZWVkZWQuIEJ1dCB0aGluayBvZiBhIGNhc2Ugd2hlcmUgU0RQ IGFuc3dlcmVyIGRvZXMgbm90IHN1cHBvcnQgYT1zc3JjLWdyb3VwOkZJRCBhbmQgYWxzbyBhc3Nv Y2lhdGVkIHJldHJhbnNtaXNzaW9uIOKAmGFwdOKAmSBwYXlsb2FkIHRoZW4gaXQgd2lsbCBub3Qg aW5jbHVkZSB0aGVtIGluIFNEUCBhbnN3ZXIuIEJ1dCBpdCBuZWVkcyB0byBrbm93IHdoaWNoIHNz cmMgaXMgYXNzb2NpYXRlZCB0byB0aGUgb3JpZ2luYWwgcGF5bG9hZCBzbyB0aGF0IGl0IGFsbG93 cyBvbmx5IHRoYXQgc3NyYy4NCg0KPC9SYWp1Pg0KDQpCUg0KUmFqdQ0KDQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E5EC923US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IHRoaW5raW5nIGxvdWQmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtBcyBs b25nIGFzIHRoZXJlIGlzIGVub3VnaCBpbmZvcm1hdGlvbiB0byB1bmFiaWdvdXNseSBtYXAgdGhl IGluY29taW5nIHN0cmVhbXMgdG8gdGhlIFNEUCwgaSBkb250IHNlZSB3ZSBuZWVkIGFueSBtb3Jl IGluZm9ybWF0aW9uIHRvIGJlIGFkZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGZlZWwgdGhlIGNvbWJpbmF0aW9uIG9mIFNTUkMgYW5k IFBheWxvYWQgVHlwZSBpbiB0aGUgUlRQIHBhY2tldCBpcyBnb29kIGVub3VnaCB0byBmaW5kIHRo ZSBtYXBwaW5nIHRvIHRoZSBhcHByb3ByaWF0ZSBtZWRpYSBsaW5lIChpZiB0aGUgUFRzIGFyZSBu b3QgcmVwZWF0ZWQpIHdoZW4gbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpbiB0aGUgaW5pdGlhbCBleGFtcGxlcyBhYm92ZSwg c3NyYy1ncm91cCBjb21tdW5pY2F0ZWQgaW4gU0RQIGFsb25nIHdpdGggc2VtYW50aWNzIChGRUMs RklEKSB3aGVuIGFwcGxpZWQgdG8gaW5jb21pbmcgU1NSQ3MgYW5kIHRoZSBhc3NvY2lhdGVkIHBh eWxvYWQgdHlwZSBoYXMgYWxsIHRoZSBuZWVkZWQgaW5mbyBmb3IgdGhlIHJlY2VpdmVyIHRvIGRl bXV4IGF0IHRoZSBydHAgbGV2ZWwgYXMgd2VsbCBhcw0KIG1hcCBhdCB0aGUgU0RQIGxldmVsLiBU aHVzIGkgZG9udCBzZWUgYSBuZWVkIGZvciBzcGVjaWZ5aW5nIFBUIGFzc29jaWF0aW9uIGV4cGxp Y2l0bHkgaW4gU0RQIGZvciB0aGUgc3NyYy1ncm91cHMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jmx0O1JhanUmZ3Q7PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Rm9yIGEgc2ltcGxlIFNEUCBvZmZlci9hbnN3ZXIgY2FzZSBpdCBpcyBwcm9iYWJseSBu b3QgbmVlZGVkLiBCdXQgdGhpbmsgb2YgYSBjYXNlIHdoZXJlIFNEUCBhbnN3ZXJlciBkb2VzIG5v dCBzdXBwb3J0IGE9c3NyYy1ncm91cDpGSUQgYW5kIGFsc28gYXNzb2NpYXRlZA0KIHJldHJhbnNt aXNzaW9uIOKAmGFwdOKAmSBwYXlsb2FkIHRoZW4gaXQgd2lsbCBub3QgaW5jbHVkZSB0aGVtIGlu IFNEUCBhbnN3ZXIuIEJ1dCBpdCBuZWVkcyB0byBrbm93IHdoaWNoIHNzcmMgaXMgYXNzb2NpYXRl ZCB0byB0aGUgb3JpZ2luYWwgcGF5bG9hZCBzbyB0aGF0IGl0IGFsbG93cyBvbmx5IHRoYXQgc3Ny Yy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7L1JhanUmZ3Q7PG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWp1PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E5EC923US70UWXCHMBA02z_-- From nobody Wed Oct 22 13:14:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772961A1AA5 for ; Wed, 22 Oct 2014 13:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.191 X-Spam-Level: X-Spam-Status: No, score=0.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTORdWbdldgc for ; Wed, 22 Oct 2014 13:14:49 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5954E1A1A38 for ; Wed, 22 Oct 2014 13:14:33 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id DEB3DA06D4DFA; Wed, 22 Oct 2014 20:14:29 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9MKEWPo001105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 16:14:32 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 16:14:32 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Bernard Aboba , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw8eqhMgAAS3uA= Date: Wed, 22 Oct 2014 20:14:31 +0000 Message-ID: References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> In-Reply-To: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5EC998US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ncvuZmCgUTPEfo_2AP0AqRrKobY Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 20:14:52 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5EC998US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U0RQIHNwZWNpZmllcyBwYXlsb2FkIHR5cGVzIGZvciBSRUQvVUxQRkVDL1JUWCBzbyBhcyB0byBh bGxvdyBkaWZmZXJlbnRpYXRpb24gd2l0aGluIGFuIHNzcmMtZ3JvdXAuIFNvIHdoaWxlIGFuIGZt dHA6IGF0dHJpYnV0ZSBjb3VsZCBiZSB1c2VkIHRvIGRlbm90ZSBhIG1lZGlhIHN0cmVhbSBvbiBh biBhOnNzcmMgbGluZSwgaXQgaXMgbm90IG5lY2Vzc2FyeS4NCjxSYWp1Pg0KV2hhdCBpZiB0aGUg YW5zd2VyZXIgd2FudHMgdG8gcmVqZWN0IGE9c3NyYy1ncm91cDpGSUQgKGFuZCBhPWZtdHA6OTgg YXB0PTk2O3J0eC10aW1lPTMwMDApIHRoZW4gd2hpY2ggb2YgdGhlIHR3byBzc3JjcyBpdCBjYW4g ZXhwZWN0IHRvIHJlY2VpdmUgZm9yIHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24/DQo8L1JhanU+ DQoNCkJSDQpSYWp1DQoNClJGQyA1MTc2IEV4YW1wbGUgMyBnaXZlcyBhbiBleGFtcGxlIHdpdGgg dHdvIGNhbWVyYXMgaW4gd2hpY2ggdGhlcmUgYXJlIHR3byBzc3JjLWdyb3VwIGxpbmVzIChvbmUg Zm9yIGVhY2ggY2FtZXJhKSwgd2l0aCBwYXlsb2FkIHR5cGUgdXNlZCB0byBkaWZmZXJlbnRpYXRl IGJldHdlZW4gSC4yNjQgYW5kIFJUWCBpbiBlYWNoIHNzcmMtZ3JvdXA6DQoNCg0KbT12aWRlbyA0 OTE3NCBSVFAvQVZQRiA5NiA5OA0KDQogYT1ydHBtYXA6OTYgSC4yNjQvOTAwMDANCg0KIGE9cnRw bWFwOjk4IHJ0eC85MDAwMA0KDQogYT1mbXRwOjk4IGFwdD05NjtydHgtdGltZT0zMDAwDQoNCiBh PXNzcmMtZ3JvdXA6RklEIDExMTExIDIyMjIyDQoNCiBhPXNzcmM6MTExMTEgY25hbWU6dXNlcjNA ZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tPg0KDQogYT1zc3JjOjIyMjIyIGNuYW1lOnVz ZXIzQGV4YW1wbGUuY29tPGh0dHA6Ly9leGFtcGxlLmNvbT4NCg0KIGE9c3NyYy1ncm91cDpGSUQg MzMzMzMgNDQ0NDQNCg0KIGE9c3NyYzozMzMzMyBjbmFtZTp1c2VyM0BleGFtcGxlLmNvbTxodHRw Oi8vZXhhbXBsZS5jb20+DQoNCiBhPXNzcmM6NDQ0NDQgY25hbWU6dXNlcjNAZXhhbXBsZS5jb208 aHR0cDovL2V4YW1wbGUuY29tPg0KDQoNCkkgYmVsaWV2ZSB0aGF0IFJGQyA1MTc2IGluY2x1ZGVz IHRoZSB0d28gZ3JvdXBzIHRvIG1ha2UgY2xlYXIgdGhhdCB0aGVyZSBhcmUgdHdvIHNvdXJjZXMg c28gdGhhdCB0aGUgQW5zd2VyZXIgbWlnaHQgY2hvb3NlIHRvIHJlamVjdCB0aGUgbS1saW5lIGlm IGl0IGNhbm5vdCBoYW5kbGUgdGhhdC4gRnJvbSBSRkMgNTE3NiBTZWN0aW9uIDg6DQoNCg0KV2hl biB1c2VkIHdpdGggdGhlIFNEUCBPZmZlci9BbnN3ZXIgTW9kZWwgW1JGQzMyNjQ8aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjMzI2ND5dLCBTRFAgc291cmNlLXNwZWNpZmljIGF0dHJpYnV0 ZXMgZGVzY3JpYmUgb25seSB0aGUgc291cmNlcyB0aGF0IGVhY2ggcGFydHkgaXMgd2lsbGluZyB0 byBzZW5kICh3aGV0aGVyIGl0IGlzIHNlbmRpbmcgUlRQIGRhdGEgb3IgUlRDUCByZXBvcnQgYmxv Y2tzKS4gTm8gbWVjaGFuaXNtIGlzIHByb3ZpZGVkIGJ5IHdoaWNoIGFuIGFuc3dlciBjYW4gYWNj ZXB0IG9yIHJlamVjdCBpbmRpdmlkdWFsIHNvdXJjZXMgd2l0aGluIGEgbWVkaWEgc3RyZWFtOyBp ZiB0aGUgc2V0IG9mIHNvdXJjZXMgaW4gYSBtZWRpYSBzdHJlYW0gaXMgdW5hY2NlcHRhYmxlLCB0 aGUgYW5zd2VyZXIncyBvbmx5IG9wdGlvbiBpcyB0byByZWplY3QgdGhlIG1lZGlhIHN0cmVhbSBv ciB0aGUgZW50aXJlIG11bHRpbWVkaWEgc2Vzc2lvbi4NCg0KDQpOb3RlIHRoYXQgaW4gdGhlIGV4 YW1wbGUgaW4gUkZDIDQ1ODggU2VjdGlvbiA4Ljggd2hlcmUgdGhlcmUgaXMgb25seSBvbmUgc291 cmNlLCB0aGVyZSBhcmUgbm8gc3NyYy1ncm91cCBsaW5lcyBhdCBhbGw6DQoNCg0KIHY9MA0KDQog bz1tYXNjaGEgMjk4MDY3NTIyMSAyOTgwNjc1Nzc4IElOIElQNCBob3N0LmV4YW1wbGUubmV0PGh0 dHA6Ly9ob3N0LmV4YW1wbGUubmV0Pg0KDQogYz1JTiBJUDQgMTkyLjAuMi4wDQoNCiBtPXZpZGVv IDQ5MTcwIFJUUC9BVlBGIDk2IDk3DQoNCiBhPXJ0cG1hcDo5NiBNUDRWLUVTLzkwMDAwDQoNCiBh PXJ0Y3AtZmI6OTYgbmFjaw0KDQogYT1mbXRwOjk2IHByb2ZpbGUtbGV2ZWwtaWQ9ODtjb25maWc9 MDEwMTAwMDAwMTIwMDA4ODQwMDY2ODJDMjA5MEEyMUYNCg0KIGE9cnRwbWFwOjk3IHJ0eC85MDAw MA0KDQogYT1mbXRwOjk3IGFwdD05NjtydHgtdGltZT0zMDAwDQoNClRoZSBzaXR1YXRpb24gd291 bGQgYmUgdGhlIHNhbWUgZm9yIEZFQyBncm91cHMgY3JlYXRlZCB2aWEgc3NyYy1ncm91cDpGRUMu IEZyb20NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZW5ub3gtcGF5bG9hZC11 bHAtc3NyYy1tdXggIDoNCg0KDQpUaGUgRkVDIGFuZCB0aGUgcGF5bG9hZCBNQVkgYWxzbyBiZSBt dWx0aXBsZXhlZCBieSBTU1JDIGludG8gb25lIHNpbmdsZSBSVFAgc2Vzc2lvbiwgd2l0aCBzZXBh cmF0ZSBTU1JDIHZhbHVlcywgaWYgdGhlIGFzc29jaWF0aW9uIGJldHdlZW4gRkVDIGFuZCBwYXls b2FkIHN0cmVhbXMgYXJlIGNvbW11bmljYXRlZCB0byBhbGwgbWVtYmVycyBvZiB0aGUgc2Vzc2lv bi4gSWYgU0RQIGlzIHVzZWQsIHRoaXMgYXNzb2NpYXRpb24gTUFZIGJlIGNvbW11bmljYXRlZCB0 aHJvdWdoIHRoZSBGRUMgc3NyYy1ncm91cCBzZW1hbnRpYyBbUkZDNTU3NjxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTU3Nj5dOyBvdGhlciBtZWNoYW5pc21zIGFyZSBhbHNvIHBvc3Np YmxlLiBSZWNlaXZlcnMgTVVTVCBOT1QgYXR0ZW1wdCB0byBpbnRlcnByZXQgRkVDIHN0cmVhbXMg Zm9yIHdoaWNoIHRoZXkgZG8gbm90IGhhdmUgaW5mb3JtYXRpb24gdG8gYXNzb2NpYXRlIHRoZW0g d2l0aCB0aGUgY29ycmVzcG9uZGluZyBwYXlsb2FkIHN0cmVhbXMuDQoNCg0KDQpPbiBPY3QgMjEs IDIwMTQsIGF0IDExOjM2IEFNLCBJw7Fha2kgQmF6IENhc3RpbGxvIDxpYmNAYWxpYXgubmV0PG1h aWx0bzppYmNAYWxpYXgubmV0Pj4gd3JvdGU6DQoNCkkgaG9wZSBJIGNhbiBydWxlIG15IFNEUCBs b2dpYyBiYXNlZCBvbiBzdGFuZGFyZHMgcmF0aGVyIHRoYW4gb24gaG93IENocm9tZSBpbXBsZW1l bnRzIHNvbWUgZmVhdHVyZXMuDQoNCk15IHF1ZXN0aW9uIHdhcyBnZW5lcmljOiBpZiBJIHJlY2Vp dmUgdGhlIGFib3ZlIFNEUCwgaG93IGRvIEkga25vdyB3aGljaCBwYXlsb2FkcyBlYWNoIHNzcmMg aXMgc3VwcG9zZWQgdG8gdHJhbnNwb3J0Pw0KT24gMjEgT2N0IDIwMTQgMTk6NTcsICJQZXRlciBU aGF0Y2hlciIgPHB0aGF0Y2hlckBnb29nbGUuY29tPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNv bT4+IHdyb3RlOg0KSSdtIG5vdCBzdXJlIHdoZXJlIGl0J3Mgc3BlY2lmaWVkLCBidXQgaGVyZSdz IHdoZXJlIGl0J3MgaW1wbGVtZW50ZWQ6DQoNCmh0dHBzOi8vY29kZS5nb29nbGUuY29tL3Avd2Vi cnRjL3NvdXJjZS9icm93c2UvdHJ1bmsvdGFsay9tZWRpYS93ZWJydGMvd2VicnRjdmlkZW9lbmdp bmUuY2MjNDEwOA0KDQpJdCBvbmx5IHN1cHBvcnRzIDIgU1NSQ3MgZm9yIGEgRklEIGdyb3VwLiAg SXQgd291bGQgaWdub3JlIGFueSBtb3JlIHRoYW4gdGhhdC4NCg0KT24gVHVlLCBPY3QgMjEsIDIw MTQgYXQgMTA6NDAgQU0sIEnDsWFraSBCYXogQ2FzdGlsbG8gPGliY0BhbGlheC5uZXQ8bWFpbHRv OmliY0BhbGlheC5uZXQ+PiB3cm90ZToNCg0KSG93IGlzIHRoYXQ/IFdoZXJlIGlzIHRoYXQgc3Bl Y2lmaWVkPyBXaGF0IGFib3V0IGlmIEkgaW5jbHVkZSAzIHNzcmMgdmFsdWVzIGluIHRoZSBzc3Jj LWdyb3VwPyBXaGF0IGlzIGVhY2ggb25lIGZvcj8NCk9uIDIxIE9jdCAyMDE0IDE5OjMxLCAiUGV0 ZXIgVGhhdGNoZXIiIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdvb2ds ZS5jb20+PiB3cm90ZToNCjM0NTI1OTg2NSBpcyAicmVhbCINCjI2OTM3NTYyNDk8dGVsOjI2OTM3 NTYyNDk+IGlzIHJ0eA0KDQpPbiBUdWUsIE9jdCAyMSwgMjAxNCBhdCA5OjI1IEFNLCBJw7Fha2kg QmF6IENhc3RpbGxvIDxpYmNAYWxpYXgubmV0PG1haWx0bzppYmNAYWxpYXgubmV0Pj4gd3JvdGU6 DQpIaSwNCg0KTWF5IEkga25vdyB3aGljaCBTU1JDICgzNDUyNTk4NjUgb3IgMjY5Mzc1NjI0OTx0 ZWw6MjY5Mzc1NjI0OT4pIHdpbGwgYmUgdXNlZCBmb3IgdGhlDQpyZWFsIG1lZGlhIHN0cmVhbSAo cGx1cyBSRUQgYW5kIEZFQykgYW5kIHdoaWNoIFNTUkMgd2lsbCBiZSB1c2VkIGZvcg0KUlRYPw0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCm09dmlkZW8gNjIxNjQgUlRQL1NBVlBG IDEwMCAxMTYgMTE3IDk2DQphPW1pZDp2aWRlbw0KYT1ydHBtYXA6MTAwIFZQOC85MDAwMA0KYT1y dHBtYXA6MTE2IHJlZC85MDAwMA0KYT1ydHBtYXA6MTE3IHVscGZlYy85MDAwMA0KYT1ydHBtYXA6 OTYgcnR4LzkwMDAwDQphPWZtdHA6OTYgYXB0PTEwMA0KYT1zc3JjLWdyb3VwOkZJRCAzNDUyNTk4 NjUgMjY5Mzc1NjI0OTx0ZWw6MjY5Mzc1NjI0OT4NCmE9c3NyYzozNDUyNTk4NjUgY25hbWU6ZXJT N0UvS0hMWUtUZWpOcw0KYT1zc3JjOjM0NTI1OTg2NSBtc2lkOkRXcFdjdDliV0t6VE1OWVpuNWJL Vmd3WjhNZnkyRXRmcUJZNQ0KYzAxMzRmMDUtZTdjMi00YWZkLWE5NzktNGUyMjRkZTVlYjkxDQph PXNzcmM6MzQ1MjU5ODY1IG1zbGFiZWw6RFdwV2N0OWJXS3pUTU5ZWm41YktWZ3daOE1meTJFdGZx Qlk1DQphPXNzcmM6MzQ1MjU5ODY1IGxhYmVsOmMwMTM0ZjA1LWU3YzItNGFmZC1hOTc5LTRlMjI0 ZGU1ZWI5MQ0KYT1zc3JjOjI2OTM3NTYyNDk8dGVsOjI2OTM3NTYyNDk+IGNuYW1lOmVyUzdFL0tI TFlLVGVqTnMNCmE9c3NyYzoyNjkzNzU2MjQ5PHRlbDoyNjkzNzU2MjQ5PiBtc2lkOkRXcFdjdDli V0t6VE1OWVpuNWJLVmd3WjhNZnkyRXRmcUJZNQ0KYzAxMzRmMDUtZTdjMi00YWZkLWE5NzktNGUy MjRkZTVlYjkxDQphPXNzcmM6MjY5Mzc1NjI0OTx0ZWw6MjY5Mzc1NjI0OT4gbXNsYWJlbDpEV3BX Y3Q5YldLelRNTllabjViS1Znd1o4TWZ5MkV0ZnFCWTUNCmE9c3NyYzoyNjkzNzU2MjQ5PHRlbDoy NjkzNzU2MjQ5PiBsYWJlbDpjMDEzNGYwNS1lN2MyLTRhZmQtYTk3OS00ZTIyNGRlNWViOTENCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0KUkZDIDU1NzYgZG9lcyBub3Qg Y2xhcmlmeSBpdCBhdCBhbGw6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1NzYj c2VjdGlvbi00LjINCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCjQuMi4gIFRoZSAic3NyYy1ncm91cCIgTWVkaWEgQXR0cmlidXRlDQoNCiAgIGE9 c3NyYy1ncm91cDo8c2VtYW50aWNzPiA8c3NyYy1pZD4gLi4uDQoNCiAgIFsuLl0NCg0KICAgVGhl IDxzZW1hbnRpY3M+IHBhcmFtZXRlciBpcyB0YWtlbiBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uIG9m IHRoZQ0KICAgImdyb3VwIiBhdHRyaWJ1dGUgW1JGQzMzODhdLiAgVGhlIGluaXRpYWwgc2VtYW50 aWMgdmFsdWVzIGRlZmluZWQgZm9yDQogICB0aGUgInNzcmMtZ3JvdXAiIGF0dHJpYnV0ZSBhcmUg RklEIChGbG93IElkZW50aWZpY2F0aW9uKSBbUkZDMzM4OF0NCiAgIGFuZCBGRUMgKEZvcndhcmQg RXJyb3IgQ29ycmVjdGlvbikgW1JGQzQ3NTZdLiAgSW4gZWFjaCBjYXNlLCB0aGUNCiAgIHJlbGF0 aW9uc2hpcCBhbW9uZyB0aGUgZ3JvdXBlZCBzb3VyY2VzIGlzIHRoZSBzYW1lIGFzIHRoZQ0KICAg cmVsYXRpb25zaGlwIGFtb25nIGNvcnJlc3BvbmRpbmcgc291cmNlcyBpbiBtZWRpYSBzdHJlYW1z IGdyb3VwZWQNCiAgIHVzaW5nIHRoZSBTRFAgImdyb3VwIiBhdHRyaWJ1dGUuDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KVGhlIHJlZmVy ZW5jZWQgUkZDIDMzODggbmVpdGhlciBjbGFyaWZpZXMgaXQ6DQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KNy40IEZJRCBTZW1hbnRpY3MNCg0K ICAgU2V2ZXJhbCAibSIgbGluZXMgZ3JvdXBlZCB0b2dldGhlciB1c2luZyBGSUQgc2VtYW50aWNz IGZvcm0gYSBtZWRpYQ0KICAgZmxvdy4gIEEgbWVkaWEgYWdlbnQgaGFuZGxpbmcgYSBtZWRpYSBm bG93IHRoYXQgY29tcHJpc2VzIHNldmVyYWwgIm0iDQogICBsaW5lcyBNVVNUIHNlbmQgYSBjb3B5 IG9mIHRoZSBtZWRpYSB0byBldmVyeSAibSIgbGluZSBwYXJ0IG9mIHRoZQ0KICAgZmxvdyBhcyBs b25nIGFzIHRoZSBjb2RlY3MgYW5kIHRoZSBkaXJlY3Rpb24gYXR0cmlidXRlIHByZXNlbnQgaW4g YQ0KICAgcGFydGljdWxhciAibSIgbGluZSBhbGxvdyBpdC4NCg0KICAgSXQgaXMgYXNzdW1lZCB0 aGF0IHRoZSBhcHBsaWNhdGlvbiB1c2VzIG9ubHkgb25lIGNvZGVjIGF0IGEgdGltZSB0bw0KICAg ZW5jb2RlIHRoZSBtZWRpYSBwcm9kdWNlZC4gIFRoaXMgY29kZWMgTUFZIGNoYW5nZSBkeW5hbWlj YWxseSBkdXJpbmcNCiAgIHRoZSBzZXNzaW9uLCBidXQgYXQgYW55IHBhcnRpY3VsYXIgbW9tZW50 IG9ubHkgb25lIGNvZGVjIGlzIGluIHVzZS4NCg0KICAgVGhlIGFwcGxpY2F0aW9uIGVuY29kZXMg dGhlIG1lZGlhIHVzaW5nIHRoZSBjdXJyZW50IGNvZGVjIGFuZCBjaGVja3MNCiAgIG9uZSBieSBv bmUgYWxsIHRoZSAibSIgbGluZXMgdGhhdCBhcmUgcGFydCBvZiB0aGUgZmxvdy4gIElmIGENCiAg IHBhcnRpY3VsYXIgIm0iIGxpbmUgY29udGFpbnMgdGhlIGNvZGVjIGJlaW5nIHVzZWQgYW5kIHRo ZSBkaXJlY3Rpb24NCiAgIGF0dHJpYnV0ZSBpcyAic2VuZG9ubHkiIG9yICJzZW5kcmVjdiIsIGEg Y29weSBvZiB0aGUgZW5jb2RlZCBtZWRpYSBpcw0KICAgc2VudCB0byB0aGUgYWRkcmVzcy9wb3J0 IHNwZWNpZmllZCBpbiB0aGF0IHBhcnRpY3VsYXIgbWVkaWEgc3RyZWFtLg0KICAgSWYgZWl0aGVy IHRoZSAibSIgbGluZSBkb2VzIG5vdCBjb250YWluIHRoZSBjb2RlYyBiZWluZyB1c2VkIG9yIHRo ZQ0KICAgZGlyZWN0aW9uIGF0dHJpYnV0ZSBpcyBuZWl0aGVyICJzZW5kb25seSIgbm9yICJzZW5k cmVjdiIsIG5vdGhpbmcgaXMNCiAgIHNlbnQgb3ZlciB0aGlzIG1lZGlhIHN0cmVhbS4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0K U28sIGhvdyBpcyB0aGUgdXNhZ2Ugb2Ygc3NyYy1ncm91cD8gV2hlcmUgaXMgaXQgcmVhbGx5IGRl ZmluZWQ/DQoNCkNhbiBJIHB1dCBtb3JlIHRoYW4gMiBzc3JjIHRvZ2V0aGVyIGluIHRoZSBzYW1l IHNzcmMtZ3JvdXAgbGluZT8NCg0KSG93IHNob3VsZCB0aGUgcmVjZWl2ZXIgaW50ZXJwcmV0IGl0 Pw0KDQpEb2VzIGEgc3NyYy1ncm91cCBhbHdheXMgbWVhbiBSVFggdXNhZ2U/IFdoZXJlIGlzIHRo YXQgc3BlY2lmaWVkIGluDQp0aGUgYWJvdmUgU0RQPw0KDQpEb2VzIG5vdCB0aGUgYWJvdmUgU0RQ IGxvb2sgYSBjb21wbGV0ZSBtaXh0dXJlIG9mIGhhY2tzIGFuZCB3b3JrYXJvdW5kcz8NCg0KDQoN Cg0KLS0NCknDsWFraSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0PG1haWx0bzppYmNAYWxp YXgubmV0Pj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2Vi IG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E5EC998US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VUlDVEZvbnRUZXh0U3R5bGVCb2R5Ow0KCXBhbm9z ZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNEUCBzcGVjaWZpZXMgcGF5bG9h ZCB0eXBlcyBmb3IgUkVEL1VMUEZFQy9SVFggc28gYXMgdG8gYWxsb3cgZGlmZmVyZW50aWF0aW9u IHdpdGhpbiBhbiBzc3JjLWdyb3VwLiBTbyB3aGlsZSBhbiBmbXRwOiBhdHRyaWJ1dGUgY291bGQg YmUgdXNlZCB0byBkZW5vdGUgYSBtZWRpYSBzdHJlYW0gb24gYW4gYTpzc3JjIGxpbmUsIGl0IGlz IG5vdCBuZWNlc3NhcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O1JhanUmZ3Q7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGlmIHRo ZSBhbnN3ZXJlciB3YW50cyB0byByZWplY3QgYT1zc3JjLWdyb3VwOkZJRCAoYW5kIGE9Zm10cDo5 OCBhcHQ9OTY7cnR4LXRpbWU9MzAwMCkgdGhlbiB3aGljaCBvZiB0aGUgdHdvIHNzcmNzIGl0IGNh biBleHBlY3QgdG8gcmVjZWl2ZSBmb3IgdGhlDQogb3JpZ2luYWwgdHJhbnNtaXNzaW9uPyA8bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7L1JhanUmZ3Q7PG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWp1PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDIDUxNzYgRXhhbXBsZSAzIGdp dmVzIGFuIGV4YW1wbGUgd2l0aCB0d28gY2FtZXJhcyBpbiB3aGljaCB0aGVyZSBhcmUgdHdvIHNz cmMtZ3JvdXAgbGluZXMgKG9uZSBmb3IgZWFjaCBjYW1lcmEpLCB3aXRoIHBheWxvYWQgdHlwZSB1 c2VkIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBILjI2NCBhbmQgUlRYIGluIGVhY2ggc3NyYy1n cm91cDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZv bnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5tPXZpZGVvIDQ5MTc0IFJU UC9BVlBGIDk2IDk4Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtV SUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwO2E9cnRw bWFwOjk2IEguMjY0LzkwMDAwJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw O2E9cnRwbWFwOjk4IHJ0eC85MDAwMCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDthPWZtdHA6OTggYXB0PTk2O3J0eC10aW1lPTMwMDAmbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7YT1zc3JjLWdyb3VwOkZJRCAxMTExMSAyMjIyMiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDthPXNzcmM6MTExMTEgY25hbWU6dXNlcjNAPGEg aHJlZj0iaHR0cDovL2V4YW1wbGUuY29tIj5leGFtcGxlLmNvbTwvYT4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7YT1zc3JjOjIyMjIyIGNuYW1lOnVzZXIzQDxhIGhyZWY9 Imh0dHA6Ly9leGFtcGxlLmNvbSI+ZXhhbXBsZS5jb208L2E+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwO2E9c3NyYy1ncm91cDpGSUQgMzMzMzMgNDQ0NDQmbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7YT1zc3JjOjMzMzMzIGNuYW1lOnVzZXIzQDxh IGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbSI+ZXhhbXBsZS5jb208L2E+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwO2E9c3NyYzo0NDQ0NCBjbmFtZTp1c2VyM0A8YSBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20iPmV4YW1wbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VUlD VEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnIgY2xlYXI9ImFs bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cHJlIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgYmVsaWV2 ZSB0aGF0IFJGQyA1MTc2IGluY2x1ZGVzIHRoZSB0d28gZ3JvdXBzIHRvIG1ha2UgY2xlYXIgdGhh dCB0aGVyZSBhcmUgdHdvIHNvdXJjZXMgc28gdGhhdCB0aGUgQW5zd2VyZXIgbWlnaHQgY2hvb3Nl IHRvIHJlamVjdCB0aGUgbS1saW5lIGlmIGl0IGNhbm5vdCBoYW5kbGUgdGhhdC4mbmJzcDtGcm9t IFJGQyA1MTc2IFNlY3Rpb24gODo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9k eSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5 bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XaGVuIHVzZWQgd2l0aCB0aGUgU0RQIE9m ZmVyL0Fuc3dlciBNb2RlbCBbPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzMyNjQiIHRpdGxlPSImcXVvdDtBbiBPZmZlci9BbnN3ZXIgTW9kZWwgd2l0aCBTZXNz aW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApJnF1b3Q7Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5SRkMzMjY0PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZv bnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5dLCBTRFAgc291cmNlLXNw ZWNpZmljIGF0dHJpYnV0ZXMgZGVzY3JpYmUgb25seSB0aGUgc291cmNlcyB0aGF0IGVhY2ggcGFy dHkgaXMgd2lsbGluZyB0byBzZW5kICh3aGV0aGVyIGl0IGlzIHNlbmRpbmcgUlRQIGRhdGEgb3Ig UlRDUCByZXBvcnQgYmxvY2tzKS4gTm8gbWVjaGFuaXNtIGlzIHByb3ZpZGVkIGJ5IHdoaWNoIGFu IGFuc3dlciBjYW4gYWNjZXB0IG9yIHJlamVjdCBpbmRpdmlkdWFsIHNvdXJjZXMgd2l0aGluIGEg bWVkaWEgc3RyZWFtOyBpZiB0aGUgc2V0IG9mIHNvdXJjZXMgaW4gYSBtZWRpYSBzdHJlYW0gaXMg dW5hY2NlcHRhYmxlLCB0aGUgYW5zd2VyZXIncyBvbmx5IG9wdGlvbiBpcyB0byByZWplY3QgdGhl IG1lZGlhIHN0cmVhbSBvciB0aGUgZW50aXJlIG11bHRpbWVkaWEgc2Vzc2lvbi48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJy IGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0K PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5Ob3RlIHRoYXQgaW4gdGhlIGV4YW1wbGUgaW4gUkZDIDQ1ODggU2VjdGlvbiA4Ljggd2hlcmUg dGhlcmUgaXMgb25seSBvbmUgc291cmNlLCB0aGVyZSBhcmUgbm8gc3NyYy1ncm91cCBsaW5lcyBh dCBhbGw6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7dj0wJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPiZuYnNwO289bWFzY2hhIDI5ODA2NzUyMjEgMjk4MDY3NTc3OCBJTiBJUDQgPGEgaHJlZj0i aHR0cDovL2hvc3QuZXhhbXBsZS5uZXQiPmhvc3QuZXhhbXBsZS5uZXQ8L2E+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwO2M9SU4gSVA0IDE5Mi4wLjIuMCZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDttPXZpZGVvIDQ5MTcwIFJUUC9BVlBGIDk2IDk3 Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRT dHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwO2E9cnRwbWFwOjk2IE1QNFYt RVMvOTAwMDAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RG b250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7YT1ydGNwLWZi Ojk2IG5hY2smbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RG b250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7YT1mbXRwOjk2 IHByb2ZpbGUtbGV2ZWwtaWQ9ODtjb25maWc9MDEwMTAwMDAwMTIwMDA4ODQwMDY2ODJDMjA5MEEy MUYmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4 dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7YT1ydHBtYXA6OTcgcnR4 LzkwMDAwJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9u dFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwO2E9Zm10cDo5NyBh cHQ9OTY7cnR4LXRpbWU9MzAwMDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2l0dWF0aW9uIHdvdWxkIGJlIHRoZSBzYW1l IGZvciBGRUMgZ3JvdXBzIGNyZWF0ZWQgdmlhIHNzcmMtZ3JvdXA6RkVDLiBGcm9tJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVubm94LXBheWxvYWQtdWxwLXNz cmMtbXV4Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVubm94LXBheWxvYWQt dWxwLXNzcmMtbXV4PC9hPiAmbmJzcDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+VGhlIEZFQyBhbmQgdGhlIHBheWxvYWQgTUFZIGFsc28gYmUgbXVsdGlwbGV4ZWQgYnkgU1NS QyBpbnRvIG9uZSBzaW5nbGUgUlRQIHNlc3Npb24sIHdpdGggc2VwYXJhdGUgU1NSQyB2YWx1ZXMs IGlmIHRoZSBhc3NvY2lhdGlvbiBiZXR3ZWVuIEZFQyBhbmQgcGF5bG9hZCBzdHJlYW1zIGFyZSBj b21tdW5pY2F0ZWQgdG8gYWxsIG1lbWJlcnMgb2YgdGhlIHNlc3Npb24uIElmIFNEUCBpcyB1c2Vk LCB0aGlzIGFzc29jaWF0aW9uIE1BWSBiZSBjb21tdW5pY2F0ZWQgdGhyb3VnaCB0aGUgRkVDIHNz cmMtZ3JvdXAgc2VtYW50aWMgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM1NTc2IiB0aXRsZT0iJnF1b3Q7U291cmNlLVNwZWNpZmljIE1lZGlhIEF0dHJpYnV0ZXMgaW4g dGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkmcXVvdDsiPlJGQzU1NzY8L2E+ XTsgb3RoZXIgbWVjaGFuaXNtcyBhcmUgYWxzbyBwb3NzaWJsZS4gUmVjZWl2ZXJzIE1VU1QgTk9U IGF0dGVtcHQgdG8gaW50ZXJwcmV0IEZFQyBzdHJlYW1zIGZvciB3aGljaCB0aGV5IGRvIG5vdCBo YXZlIGluZm9ybWF0aW9uIHRvIGFzc29jaWF0ZSB0aGVtIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcg cGF5bG9hZCBzdHJlYW1zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KT24gT2N0IDIxLCAyMDE0LCBhdCAxMTozNiBBTSwgScOxYWtpIEJheiBDYXN0aWxsbyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiPmliY0BhbGlheC5uZXQ8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHA+SSBob3BlIEkgY2FuIHJ1bGUg bXkgU0RQIGxvZ2ljIGJhc2VkIG9uIHN0YW5kYXJkcyByYXRoZXIgdGhhbiBvbiBob3cgQ2hyb21l IGltcGxlbWVudHMgc29tZSBmZWF0dXJlcy48bzpwPjwvbzpwPjwvcD4NCjxwPk15IHF1ZXN0aW9u IHdhcyBnZW5lcmljOiBpZiBJIHJlY2VpdmUgdGhlIGFib3ZlIFNEUCwgaG93IGRvIEkga25vdyB3 aGljaCBwYXlsb2FkcyBlYWNoIHNzcmMgaXMgc3VwcG9zZWQgdG8gdHJhbnNwb3J0PzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIxIE9jdCAyMDE0IDE5OjU3 LCAmcXVvdDtQZXRlciBUaGF0Y2hlciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hl ckBnb29nbGUuY29tIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSdt IG5vdCBzdXJlIHdoZXJlIGl0J3Mgc3BlY2lmaWVkLCBidXQgaGVyZSdzIHdoZXJlIGl0J3MgaW1w bGVtZW50ZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczov L2NvZGUuZ29vZ2xlLmNvbS9wL3dlYnJ0Yy9zb3VyY2UvYnJvd3NlL3RydW5rL3RhbGsvbWVkaWEv d2VicnRjL3dlYnJ0Y3ZpZGVvZW5naW5lLmNjIzQxMDgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2NvZGUuZ29vZ2xlLmNvbS9wL3dlYnJ0Yy9zb3VyY2UvYnJvd3NlL3RydW5rL3RhbGsvbWVkaWEv d2VicnRjL3dlYnJ0Y3ZpZGVvZW5naW5lLmNjIzQxMDg8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXQgb25s eSBzdXBwb3J0cyAyIFNTUkNzIGZvciBhIEZJRCBncm91cC4mbmJzcDsgSXQgd291bGQgaWdub3Jl IGFueSBtb3JlIHRoYW4gdGhhdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgT2N0IDIxLCAyMDE0IGF0IDEwOjQwIEFN LCBJw7Fha2kgQmF6IENhc3RpbGxvICZsdDs8YSBocmVmPSJtYWlsdG86aWJjQGFsaWF4Lm5ldCIg dGFyZ2V0PSJfYmxhbmsiPmliY0BhbGlheC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwPkhvdyBpcyB0aGF0PyBXaGVyZSBpcyB0aGF0IHNwZWNpZmllZD8gV2hhdCBhYm91dCBp ZiBJIGluY2x1ZGUgMyBzc3JjIHZhbHVlcyBpbiB0aGUgc3NyYy1ncm91cD8gV2hhdCBpcyBlYWNo IG9uZSBmb3I/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiAyMSBPY3QgMjAxNCAxOTozMSwgJnF1b3Q7UGV0ZXIgVGhhdGNoZXImcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnB0aGF0Y2hlckBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+MzQ1MjU5ODY1IGlzICZxdW90O3JlYWwmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YSBocmVmPSJ0ZWw6MjY5Mzc1NjI0OSIgdGFyZ2V0PSJfYmxhbmsiPjI2OTM3NTYyNDk8 L2E+IGlzIHJ0eDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBPY3QgMjEsIDIwMTQgYXQgOToyNSBBTSwgScOxYWtpIEJh eiBDYXN0aWxsbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiIHRhcmdldD0iX2Js YW5rIj5pYmNAYWxpYXgubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8YnI+DQo8YnI+DQpNYXkgSSBrbm93IHdoaWNoIFNTUkMgKDM0NTI1 OTg2NSBvciA8YSBocmVmPSJ0ZWw6MjY5Mzc1NjI0OSIgdGFyZ2V0PSJfYmxhbmsiPjI2OTM3NTYy NDk8L2E+KSB3aWxsIGJlIHVzZWQgZm9yIHRoZTxicj4NCnJlYWwgbWVkaWEgc3RyZWFtIChwbHVz IFJFRCBhbmQgRkVDKSBhbmQgd2hpY2ggU1NSQyB3aWxsIGJlIHVzZWQgZm9yPGJyPg0KUlRYPzxi cj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KbT12 aWRlbyA2MjE2NCBSVFAvU0FWUEYgMTAwIDExNiAxMTcgOTY8YnI+DQphPW1pZDp2aWRlbzxicj4N CmE9cnRwbWFwOjEwMCBWUDgvOTAwMDA8YnI+DQphPXJ0cG1hcDoxMTYgcmVkLzkwMDAwPGJyPg0K YT1ydHBtYXA6MTE3IHVscGZlYy85MDAwMDxicj4NCmE9cnRwbWFwOjk2IHJ0eC85MDAwMDxicj4N CmE9Zm10cDo5NiBhcHQ9MTAwPGJyPg0KYT1zc3JjLWdyb3VwOkZJRCAzNDUyNTk4NjUgPGEgaHJl Zj0idGVsOjI2OTM3NTYyNDkiIHRhcmdldD0iX2JsYW5rIj4yNjkzNzU2MjQ5PC9hPjxicj4NCmE9 c3NyYzozNDUyNTk4NjUgY25hbWU6ZXJTN0UvS0hMWUtUZWpOczxicj4NCmE9c3NyYzozNDUyNTk4 NjUgbXNpZDpEV3BXY3Q5YldLelRNTllabjViS1Znd1o4TWZ5MkV0ZnFCWTU8YnI+DQpjMDEzNGYw NS1lN2MyLTRhZmQtYTk3OS00ZTIyNGRlNWViOTE8YnI+DQphPXNzcmM6MzQ1MjU5ODY1IG1zbGFi ZWw6RFdwV2N0OWJXS3pUTU5ZWm41YktWZ3daOE1meTJFdGZxQlk1PGJyPg0KYT1zc3JjOjM0NTI1 OTg2NSBsYWJlbDpjMDEzNGYwNS1lN2MyLTRhZmQtYTk3OS00ZTIyNGRlNWViOTE8YnI+DQphPXNz cmM6PGEgaHJlZj0idGVsOjI2OTM3NTYyNDkiIHRhcmdldD0iX2JsYW5rIj4yNjkzNzU2MjQ5PC9h PiBjbmFtZTplclM3RS9LSExZS1Rlak5zPGJyPg0KYT1zc3JjOjxhIGhyZWY9InRlbDoyNjkzNzU2 MjQ5IiB0YXJnZXQ9Il9ibGFuayI+MjY5Mzc1NjI0OTwvYT4gbXNpZDpEV3BXY3Q5YldLelRNTlla bjViS1Znd1o4TWZ5MkV0ZnFCWTU8YnI+DQpjMDEzNGYwNS1lN2MyLTRhZmQtYTk3OS00ZTIyNGRl NWViOTE8YnI+DQphPXNzcmM6PGEgaHJlZj0idGVsOjI2OTM3NTYyNDkiIHRhcmdldD0iX2JsYW5r Ij4yNjkzNzU2MjQ5PC9hPiBtc2xhYmVsOkRXcFdjdDliV0t6VE1OWVpuNWJLVmd3WjhNZnkyRXRm cUJZNTxicj4NCmE9c3NyYzo8YSBocmVmPSJ0ZWw6MjY5Mzc1NjI0OSIgdGFyZ2V0PSJfYmxhbmsi PjI2OTM3NTYyNDk8L2E+IGxhYmVsOmMwMTM0ZjA1LWU3YzItNGFmZC1hOTc5LTRlMjI0ZGU1ZWI5 MTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQpSRkMgNTU3NiBkb2VzIG5vdCBjbGFyaWZ5IGl0IGF0IGFsbDo8YnI+DQo8YnI+ DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NTc2I3NlY3Rpb24tNC4y IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTU3NiNzZWN0 aW9uLTQuMjwvYT48YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCjQuMi4mbmJzcDsgVGhlICZxdW90O3NzcmMtZ3JvdXAmcXVv dDsgTWVkaWEgQXR0cmlidXRlPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO2E9c3NyYy1ncm91cDom bHQ7c2VtYW50aWNzJmd0OyAmbHQ7c3NyYy1pZCZndDsgLi4uPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwO1suLl08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlICZsdDtzZW1hbnRpY3MmZ3Q7IHBh cmFtZXRlciBpcyB0YWtlbiBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZTxicj4NCiZuYnNw OyAmbmJzcDsmcXVvdDtncm91cCZxdW90OyBhdHRyaWJ1dGUgW1JGQzMzODhdLiZuYnNwOyBUaGUg aW5pdGlhbCBzZW1hbnRpYyB2YWx1ZXMgZGVmaW5lZCBmb3I8YnI+DQombmJzcDsgJm5ic3A7dGhl ICZxdW90O3NzcmMtZ3JvdXAmcXVvdDsgYXR0cmlidXRlIGFyZSBGSUQgKEZsb3cgSWRlbnRpZmlj YXRpb24pIFtSRkMzMzg4XTxicj4NCiZuYnNwOyAmbmJzcDthbmQgRkVDIChGb3J3YXJkIEVycm9y IENvcnJlY3Rpb24pIFtSRkM0NzU2XS4mbmJzcDsgSW4gZWFjaCBjYXNlLCB0aGU8YnI+DQombmJz cDsgJm5ic3A7cmVsYXRpb25zaGlwIGFtb25nIHRoZSBncm91cGVkIHNvdXJjZXMgaXMgdGhlIHNh bWUgYXMgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO3JlbGF0aW9uc2hpcCBhbW9uZyBjb3JyZXNwb25k aW5nIHNvdXJjZXMgaW4gbWVkaWEgc3RyZWFtcyBncm91cGVkPGJyPg0KJm5ic3A7ICZuYnNwO3Vz aW5nIHRoZSBTRFAgJnF1b3Q7Z3JvdXAmcXVvdDsgYXR0cmlidXRlLjxicj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KVGhlIHJlZmVyZW5jZWQgUkZDIDMzODggbmVpdGhlciBjbGFyaWZpZXMgaXQ6PGJyPg0K PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KNy40IEZJRCBTZW1hbnRpY3M8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7U2V2ZXJhbCAm cXVvdDttJnF1b3Q7IGxpbmVzIGdyb3VwZWQgdG9nZXRoZXIgdXNpbmcgRklEIHNlbWFudGljcyBm b3JtIGEgbWVkaWE8YnI+DQombmJzcDsgJm5ic3A7Zmxvdy4mbmJzcDsgQSBtZWRpYSBhZ2VudCBo YW5kbGluZyBhIG1lZGlhIGZsb3cgdGhhdCBjb21wcmlzZXMgc2V2ZXJhbCAmcXVvdDttJnF1b3Q7 PGJyPg0KJm5ic3A7ICZuYnNwO2xpbmVzIE1VU1Qgc2VuZCBhIGNvcHkgb2YgdGhlIG1lZGlhIHRv IGV2ZXJ5ICZxdW90O20mcXVvdDsgbGluZSBwYXJ0IG9mIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtm bG93IGFzIGxvbmcgYXMgdGhlIGNvZGVjcyBhbmQgdGhlIGRpcmVjdGlvbiBhdHRyaWJ1dGUgcHJl c2VudCBpbiBhPGJyPg0KJm5ic3A7ICZuYnNwO3BhcnRpY3VsYXIgJnF1b3Q7bSZxdW90OyBsaW5l IGFsbG93IGl0Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtJdCBpcyBhc3N1bWVkIHRoYXQgdGhl IGFwcGxpY2F0aW9uIHVzZXMgb25seSBvbmUgY29kZWMgYXQgYSB0aW1lIHRvPGJyPg0KJm5ic3A7 ICZuYnNwO2VuY29kZSB0aGUgbWVkaWEgcHJvZHVjZWQuJm5ic3A7IFRoaXMgY29kZWMgTUFZIGNo YW5nZSBkeW5hbWljYWxseSBkdXJpbmc8YnI+DQombmJzcDsgJm5ic3A7dGhlIHNlc3Npb24sIGJ1 dCBhdCBhbnkgcGFydGljdWxhciBtb21lbnQgb25seSBvbmUgY29kZWMgaXMgaW4gdXNlLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgYXBwbGljYXRpb24gZW5jb2RlcyB0aGUgbWVkaWEgdXNp bmcgdGhlIGN1cnJlbnQgY29kZWMgYW5kIGNoZWNrczxicj4NCiZuYnNwOyAmbmJzcDtvbmUgYnkg b25lIGFsbCB0aGUgJnF1b3Q7bSZxdW90OyBsaW5lcyB0aGF0IGFyZSBwYXJ0IG9mIHRoZSBmbG93 LiZuYnNwOyBJZiBhPGJyPg0KJm5ic3A7ICZuYnNwO3BhcnRpY3VsYXIgJnF1b3Q7bSZxdW90OyBs aW5lIGNvbnRhaW5zIHRoZSBjb2RlYyBiZWluZyB1c2VkIGFuZCB0aGUgZGlyZWN0aW9uPGJyPg0K Jm5ic3A7ICZuYnNwO2F0dHJpYnV0ZSBpcyAmcXVvdDtzZW5kb25seSZxdW90OyBvciAmcXVvdDtz ZW5kcmVjdiZxdW90OywgYSBjb3B5IG9mIHRoZSBlbmNvZGVkIG1lZGlhIGlzPGJyPg0KJm5ic3A7 ICZuYnNwO3NlbnQgdG8gdGhlIGFkZHJlc3MvcG9ydCBzcGVjaWZpZWQgaW4gdGhhdCBwYXJ0aWN1 bGFyIG1lZGlhIHN0cmVhbS48YnI+DQombmJzcDsgJm5ic3A7SWYgZWl0aGVyIHRoZSAmcXVvdDtt JnF1b3Q7IGxpbmUgZG9lcyBub3QgY29udGFpbiB0aGUgY29kZWMgYmVpbmcgdXNlZCBvciB0aGU8 YnI+DQombmJzcDsgJm5ic3A7ZGlyZWN0aW9uIGF0dHJpYnV0ZSBpcyBuZWl0aGVyICZxdW90O3Nl bmRvbmx5JnF1b3Q7IG5vciAmcXVvdDtzZW5kcmVjdiZxdW90Oywgbm90aGluZyBpczxicj4NCiZu YnNwOyAmbmJzcDtzZW50IG92ZXIgdGhpcyBtZWRpYSBzdHJlYW0uPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NClNvLCBob3cgaXMgdGhlIHVzYWdlIG9mIHNzcmMtZ3JvdXA/IFdoZXJlIGlz IGl0IHJlYWxseSBkZWZpbmVkPzxicj4NCjxicj4NCkNhbiBJIHB1dCBtb3JlIHRoYW4gMiBzc3Jj IHRvZ2V0aGVyIGluIHRoZSBzYW1lIHNzcmMtZ3JvdXAgbGluZT88YnI+DQo8YnI+DQpIb3cgc2hv dWxkIHRoZSByZWNlaXZlciBpbnRlcnByZXQgaXQ/PGJyPg0KPGJyPg0KRG9lcyBhIHNzcmMtZ3Jv dXAgYWx3YXlzIG1lYW4gUlRYIHVzYWdlPyBXaGVyZSBpcyB0aGF0IHNwZWNpZmllZCBpbjxicj4N CnRoZSBhYm92ZSBTRFA/PGJyPg0KPGJyPg0KRG9lcyBub3QgdGhlIGFib3ZlIFNEUCBsb29rIGEg Y29tcGxldGUgbWl4dHVyZSBvZiBoYWNrcyBhbmQgd29ya2Fyb3VuZHM/PGJyPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tPGJyPg0KScOxYWtp IEJheiBDYXN0aWxsbzxicj4NCiZsdDs8YSBocmVmPSJtYWlsdG86aWJjQGFsaWF4Lm5ldCIgdGFy Z2V0PSJfYmxhbmsiPmliY0BhbGlheC5uZXQ8L2E+Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E5EC998US70UWXCHMBA02z_-- From nobody Wed Oct 22 13:36:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12571A19F7 for ; Wed, 22 Oct 2014 13:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SXVwR5Z7KY8 for ; Wed, 22 Oct 2014 13:36:27 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066721A1AFD for ; Wed, 22 Oct 2014 13:36:25 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id v63so3387919oia.13 for ; Wed, 22 Oct 2014 13:36:25 -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; bh=cKcKhq31CO1RXt5+sb9dEUuDIw5D/qqB9Ur2H+mzWf0=; b=fGhG3lXk1fOSh5k/x11ZuWVo/pj//DCJtQKi2izuov+amWOVW7UiHX7NGmnHaKXRbi iXxkOp3Ufz8W0ST2oyqU/fJoURv740PatE6kcylh7EQ4N6SfRbo5MKu3HGe7S3l/0Og5 cHWqy/KALTQVeqvXzX8/rL5QxnTiGtHDgMja/aj7fR64yKBYuW5ZHlEMUQ1vvIkyOnvg APkcA/C4ZxA7ZPtqJIFqSy3Nn5KmVDWvoQcDCJomJGpU3SiJDGyKpOx8EBYT84q/aKRI wOiZXaiPfYHZLuNmRBMaxx2UpJgxPeP94fQr7NAK6Re+YT9H3oRDsZLj36GdVwQ9SU6O z0IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cKcKhq31CO1RXt5+sb9dEUuDIw5D/qqB9Ur2H+mzWf0=; b=jzyVQPuEGPYEM4sGiNqAt4yasCp8B/95W4b0XccU6cJkAxMpmgzhSjPiB1n8t7oMdw kHc9dRSVsC8pt6KH+MoGQLIYlsrpLcf0ryS/84qM3GEt4Qsigi2r3ELbu6fH9SxlPY5G NPxAMQLNRNqzeSBS6/L8Pl1LUUN5O4Khv9Ho2N4PS5n6Uza48EYxyO1S2G7CpOOv8DJH jbRYhJr+5p17VP/mt10a5UGE+vIgEjtE+P0fyy5zE5fhYfcC7BTC14wNzb7rg/rmC4IV 3CUK0p2RUp+5U3/Dpv+7GmoR1G4KAn+Wz5AAbNiHtcGeqJIbEO3IuuhqTxDT6ebXgHQH bWvw== X-Gm-Message-State: ALoCoQmoj+I05Sj6XIQlNsMkgKH7xuJpOyqro0F8NE0NH9TQ4U3+2PT/DQOgwVT/Jx6ltWP9wX1Y X-Received: by 10.202.102.162 with SMTP id m34mr281935oik.37.1414010185354; Wed, 22 Oct 2014 13:36:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.251.230 with HTTP; Wed, 22 Oct 2014 13:36:05 -0700 (PDT) In-Reply-To: <5447C4BA.6070805@alvestrand.no> References: <5447C4BA.6070805@alvestrand.no> From: Justin Uberti Date: Wed, 22 Oct 2014 13:36:05 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1140a9beceb237050608e60e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AFw36jqDrKlGErZWcn4sFfSfAyg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 20:36:29 -0000 --001a1140a9beceb237050608e60e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yes, they need to happen. Framing is 4571. See http://tools.ietf.org/html/rfc6544#section-7.1. On Wed, Oct 22, 2014 at 7:52 AM, Harald Alvestrand wrote: > On 08/25/2014 07:36 AM, Justin Uberti wrote: > > Yes, 4571 must be used for ICE connectivity checks, when using ICE-TCP. > > However, TURN/TCP has its own framing for STUN messages. > > I would simplify your sentence to: > > If ICE-TCP connections are used, framing according to [RFC4571] MUST > be used for all packets, unless the content has its own framing > mechanism. > > > Checking the list for long-delayed updates.... > > Checking back: The change from TCP to ICE-TCP is good (this excludes > TURN-TCP from this paragraph), but the exchange leaves me uncertain about > the status of STUN packets on ICE-TCP connections. > > Do they happen at all? If they happen, should they be RFC 4571 > encapsulated, or not? > > > > > On Fri, Aug 22, 2014 at 8:38 AM, I=C3=B1aki Baz Castillo = wrote: > >> Hi, >> >> draft-ietf-rtcweb-transports-06 says: >> >> If TCP connections are used, RTP framing according to [RFC4571] MUST >> be used, both for the RTP packets and for the DTLS packets used to >> carry data channels. >> >> >> Not just RTP and DTLS, but also for STUN packets must be framed with >> RFC4571. And I do not understand why "DTLS packets used to carry data >> channels". In fact all the DTLS packets (also the ones for the >> handshake) must be framed as per RFC 4571. >> >> >> So I suggest to improve the above text as follows: >> >> If TCP connections are used, RTP framing according to [RFC4571] MUST >> be used for the STUN packets, SRTP packets, SRTCP packets and DTLS >> packets. >> >> >> >> >> >> >> -- >> I=C3=B1aki Baz Castillo >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1140a9beceb237050608e60e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yes, they need to happen. Framing is 4571. See=C2=A0http://tools.ietf.org/= html/rfc6544#section-7.1.

On Wed, Oct 22, 2014 at 7:52 AM, Harald Alvestrand <h= arald@alvestrand.no> wrote:
=20 =20 =20
On 08/25/2014 07:36 AM, Justin Uberti wrote:
Yes, 4571 must be used for ICE connectivity checks, when using ICE-TCP.

However, TURN/TCP has its own framing for STUN messages.

I would simplify your sentence to:

= =C2=A0 =C2=A0If ICE-TCP connections are used, framing according to [RFC4571] MUST
=C2= =A0 =C2=A0be used for all packets, unless the content has its own framing mechanism.

 Checking the list for long-delayed updates....

Checking back: The change from TCP to ICE-TCP is good (this excludes TURN-TCP from this paragraph), but the exchange leaves me uncertain about the status of STUN packets on ICE-TCP connections.

Do they happen at all? If they happen, should they be RFC 4571 encapsulated, or not?




On Fri, Aug 22, 2014 at 8:38 AM, I=C3=B1= aki Baz Castillo <ibc@aliax.net> wrote:
Hi,

draft-ietf-rtcweb-transports-06 says:

=C2=A0 =C2=A0If TCP connections are used, RTP framing according= to [RFC4571] MUST
=C2=A0 =C2=A0be used, both for the RTP packets and for the DTLS packets used to
=C2=A0 =C2=A0carry data channels.


Not just RTP and DTLS, but also for STUN packets must be framed with
RFC4571. And I do not understand why "DTLS packets used to carry data
channels". In fact all the DTLS packets (also the ones for the
handshake) must be framed as per RFC 4571.


So I suggest to improve the above text as follows:

=C2=A0 =C2=A0If TCP connections are used, RTP framing according= to [RFC4571] MUST
=C2=A0 =C2=A0be used for the STUN packets, SRTP packets, SRTCP = packets and DTLS
=C2=A0 =C2=A0packets.






--
I=C3=B1aki Baz Castillo
<ibc@= aliax.net>

_______________________________________________
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
Surveillance is pervasive. Go Dark.

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


--001a1140a9beceb237050608e60e-- From nobody Wed Oct 22 14:28:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E371A3BA1 for ; Wed, 22 Oct 2014 14:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h23lFO6wkvk0 for ; Wed, 22 Oct 2014 14:28:53 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34EF1A3B9D for ; Wed, 22 Oct 2014 14:28:52 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id uq10so283051igb.7 for ; Wed, 22 Oct 2014 14:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=o9vNpOnMRK6XfXwdkTZjmJBjHffMpP7Nk19sKYnBc5g=; b=OwkHBUpwBQ509gIGeigTp0vj/FmztgPuQVmDGJa2qx6Da3M3Xw7sAHu+ALm1ROHq+Q Ks5c+PcHNKU1Qey8Qpw07UxxsAV05zUuMBbpixFg3PNEmKb63tY8rJ7y9TAOjAIl3g6/ yyn1JvCXRRMsQFDc4DqMEg8p+crO9gKohl9b2wVcUtYeXrHWsNgKnSMyIYm+55ZbTJ85 lWaA3bszyI5fdISDKfkzakqSyjg3pW8FhAsn7y02fh7WUJqbp6Qgy7egccDTRE0Pgr9p R1yL7oLjTDxW+Yo80Jwpc3vBXvp37qz5kKA1iXjuTygh7wtWSKoIOZ4bevCOja4hnqHt +z8Q== X-Received: by 10.50.83.97 with SMTP id p1mr8195056igy.19.1414013331413; Wed, 22 Oct 2014 14:28:51 -0700 (PDT) Received: from [192.168.4.36] (ip-64-134-132-11.public.wayport.net. [64.134.132.11]) by mx.google.com with ESMTPSA id o62sm8069093ioe.12.2014.10.22.14.28.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 14:28:49 -0700 (PDT) References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-4FB77041-A454-473D-9415-7D95A1F5A858 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12B411) From: Bernard Aboba Date: Wed, 22 Oct 2014 14:28:37 -0700 To: "Makaraju, Maridi Raju (Raju)" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-XL7nxNTige2AvvLuDVc4qAk8nQ Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 21:28:56 -0000 --Apple-Mail-4FB77041-A454-473D-9415-7D95A1F5A858 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable RFC 5576 makes it clear that partial rejection is not supported.=20 > On Oct 22, 2014, at 1:14 PM, Makaraju, Maridi Raju (Raju) wrote: >=20 > SDP specifies payload types for RED/ULPFEC/RTX so as to allow differentiat= ion within an ssrc-group. So while an fmtp: attribute could be used to denot= e a media stream on an a:ssrc line, it is not necessary. > > What if the answerer wants to reject a=3Dssrc-group:FID (and a=3Dfmtp:98 a= pt=3D96;rtx-time=3D3000) then which of the two ssrcs it can expect to receiv= e for the original transmission? > > =20 > BR > Raju > =20 > RFC 5576 Example 3 gives an example with two cameras in which there are tw= o ssrc-group lines (one for each camera), with payload type used to differen= tiate between H.264 and RTX in each ssrc-group: > =20 > m=3Dvideo 49174 RTP/AVPF 96 98=20 > a=3Drtpmap:96 H.264/90000=20 > a=3Drtpmap:98 rtx/90000=20 > a=3Dfmtp:98 apt=3D96;rtx-time=3D3000=20 > a=3Dssrc-group:FID 11111 22222=20 > a=3Dssrc:11111 cname:user3@example.com=20 > a=3Dssrc:22222 cname:user3@example.com=20 > a=3Dssrc-group:FID 33333 44444=20 > a=3Dssrc:33333 cname:user3@example.com=20 > a=3Dssrc:44444 cname:user3@example.com >=20 > I believe that RFC 5577 includes the two groups to make clear that there a= re two sources so that the Answerer might choose to reject the m-line if it c= annot handle that. =46rom RFC 5576 Section 8: >=20 > When used with the SDP Offer/Answer Model [RFC3264], SDP source-specific a= ttributes describe only the sources that each party is willing to send (whet= her it is sending RTP data or RTCP report blocks). No mechanism is provided b= y which an answer can accept or reject individual sources within a media str= eam; if the set of sources in a media stream is unacceptable, the answerer's= only option is to reject the media stream or the entire multimedia session.= >=20 > Note that in the example in RFC 4588 Section 8.8 where there is only one s= ource, there are no ssrc-group lines at all: >=20 > v=3D0=20 > o=3Dmascha 2980675221 2980675778 IN IP4 host.example.net=20 > c=3DIN IP4 192.0.2.0=20 > m=3Dvideo 49170 RTP/AVPF 96 97=20 > a=3Drtpmap:96 MP4V-ES/90000=20 > a=3Drtcp-fb:96 nack=20 > a=3Dfmtp:96 profile-level-id=3D8;config=3D01010000012000884006682C2090A21= F=20 > a=3Drtpmap:97 rtx/90000=20 > a=3Dfmtp:97 apt=3D96;rtx-time=3D3000 > =20 > The situation would be the same for FEC groups created via ssrc-group:FEC.= =46rom=20 > https://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux : > =20 > The FEC and the payload MAY also be multiplexed by SSRC into one single RT= P session, with separate SSRC values, if the association between FEC and pay= load streams are communicated to all members of the session. If SDP is used,= this association MAY be communicated through the FEC ssrc-group semantic [R= FC5576]; other mechanisms are also possible. Receivers MUST NOT attempt to i= nterpret FEC streams for which they do not have information to associate the= m with the corresponding payload streams. > =20 > =20 >=20 > On Oct 21, 2014, at 11:36 AM, I=C3=B1aki Baz Castillo wrot= e: >=20 > I hope I can rule my SDP logic based on standards rather than on how Chrom= e implements some features. >=20 > My question was generic: if I receive the above SDP, how do I know which p= ayloads each ssrc is supposed to transport? >=20 > On 21 Oct 2014 19:57, "Peter Thatcher" wrote: > I'm not sure where it's specified, but here's where it's implemented: > =20 > https://code.google.com/p/webrtc/source/browse/trunk/talk/media/webrtc/web= rtcvideoengine.cc#4108 > =20 > It only supports 2 SSRCs for a FID group. It would ignore any more than t= hat. > =20 > On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Castillo w= rote: > How is that? Where is that specified? What about if I include 3 ssrc value= s in the ssrc-group? What is each one for? >=20 > On 21 Oct 2014 19:31, "Peter Thatcher" wrote: > 345259865 is "real" > 2693756249 is rtx > =20 > On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Castillo w= rote: > Hi, >=20 > May I know which SSRC (345259865 or 2693756249) will be used for the > real media stream (plus RED and FEC) and which SSRC will be used for > RTX? >=20 >=20 >=20 > -------------------------- > m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 > a=3Dmid:video > a=3Drtpmap:100 VP8/90000 > a=3Drtpmap:116 red/90000 > a=3Drtpmap:117 ulpfec/90000 > a=3Drtpmap:96 rtx/90000 > a=3Dfmtp:96 apt=3D100 > a=3Dssrc-group:FID 345259865 2693756249 > a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs > a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs > a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > ------------------------------- >=20 >=20 >=20 >=20 > RFC 5576 does not clarify it at all: >=20 > http://tools.ietf.org/html/rfc5576#section-4.2 >=20 > -------------------------------------------------- > 4.2. The "ssrc-group" Media Attribute >=20 > a=3Dssrc-group: ... >=20 > [..] >=20 > The parameter is taken from the specification of the > "group" attribute [RFC3388]. The initial semantic values defined for > the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] > and FEC (Forward Error Correction) [RFC4756]. In each case, the > relationship among the grouped sources is the same as the > relationship among corresponding sources in media streams grouped > using the SDP "group" attribute. > -------------------------------------------------- >=20 >=20 >=20 > The referenced RFC 3388 neither clarifies it: >=20 > --------------------------------------------------- > 7.4 FID Semantics >=20 > Several "m" lines grouped together using FID semantics form a media > flow. A media agent handling a media flow that comprises several "m" > lines MUST send a copy of the media to every "m" line part of the > flow as long as the codecs and the direction attribute present in a > particular "m" line allow it. >=20 > It is assumed that the application uses only one codec at a time to > encode the media produced. This codec MAY change dynamically during > the session, but at any particular moment only one codec is in use. >=20 > The application encodes the media using the current codec and checks > one by one all the "m" lines that are part of the flow. If a > particular "m" line contains the codec being used and the direction > attribute is "sendonly" or "sendrecv", a copy of the encoded media is > sent to the address/port specified in that particular media stream. > If either the "m" line does not contain the codec being used or the > direction attribute is neither "sendonly" nor "sendrecv", nothing is > sent over this media stream. > ---------------------------------------------------- >=20 >=20 >=20 >=20 > So, how is the usage of ssrc-group? Where is it really defined? >=20 > Can I put more than 2 ssrc together in the same ssrc-group line? >=20 > How should the receiver interpret it? >=20 > Does a ssrc-group always mean RTX usage? Where is that specified in > the above SDP? >=20 > Does not the above SDP look a complete mixture of hacks and workarounds? >=20 >=20 >=20 >=20 > -- > I=C3=B1aki Baz Castillo > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-4FB77041-A454-473D-9415-7D95A1F5A858 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
RFC 5576 makes it clear that partial r= ejection is not supported. 



On Oct 22, 2014, a= t 1:14 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

<= /div>

SDP specifies payload types for RED/ULPFEC/RTX so as t= o allow differentiation within an ssrc-group. So while an fmtp: attribute co= uld be used to denote a media stream on an a:ssrc line, it is not necessary.=

<Raju>

What if the answerer w= ants to reject a=3Dssrc-group:FID (and a=3Dfmtp:98 apt=3D96;rtx-time=3D3000)= then which of the two ssrcs it can expect to receive for the original transmission?

</Raju>

 

BR<= /i>

Raju

 

RFC 5576 Example 3 gives an example with two cameras i= n which there are two ssrc-group lines (one for each camera), with payload t= ype used to differentiate between H.264 and RTX in each ssrc-group:

 

m=3Dvideo 49174 RTP/AVPF 96 98&n=
bsp;
 a=3Drtpmap:96 H.264/90000&=
nbsp;
 a=3Drtpmap:98 rtx/90000&nb=
sp;
 a=3Dfmtp:98 apt=3D96;rtx-t=
ime=3D3000 
 a=3Dssrc-group:FID 11111 2=
2222 
 a=3Dssrc:11111 cname:user3=
@example.com 

 a=3Dssrc:22222 cname:user3=
@example.com 

 a=3Dssrc-group:FID 33333 4=
4444 


 a=3Dssrc:33333 cname:user3=
@example.com 

 a=3Dssrc:44444 cname:user3=
@example.com





I believe that RFC 5577 includes=
 the two groups to make clear that there are two sources so that the Answere=
r might choose to reject the m-line if it cannot handle that. =46rom RFC=
 5576 Section 8:





When used with the SDP Offer/Ans=
wer Model [RFC3264], SDP source-specific attributes describe only the s=
ources that each party is willing to send (whether it is sending RTP data or=
 RTCP report blocks). No mechanism is provided by which an answer can accept=
 or reject individual sources within a media stream; if the set of sources i=
n a media stream is unacceptable, the answerer's only option is to reject th=
e media stream or the entire multimedia session.





Note that in the example in RFC 4=
588 Section 8.8 where there is only one source, there are no ssrc-group line=
s at all:





 v=3D0 


 o=3Dmascha 2980675221 2980=
675778 IN IP4 host.example.net =



 c=3DIN IP4 192.0.2.0 =



 m=3Dvideo 49170 RTP/AVPF 9=
6 97 


 a=3Drtpmap:96 MP4V-ES/9000=
0 


 a=3Drtcp-fb:96 nack <=
/span>


 a=3Dfmtp:96 profile-level-=
id=3D8;config=3D01010000012000884006682C2090A21F 

 a=3Drtpmap:97 rtx/90000&nb=
sp;


 a=3Dfmtp:97 apt=3D96;rtx-t=
ime=3D3000

 

The situation would be the same for FEC groups create= d via ssrc-group:FEC. From 

 

The FEC and the payload MAY also=
 be multiplexed by SSRC into one single RTP session, with separate SSRC valu=
es, if the association between FEC and payload streams are communicated to a=
ll members of the session. If SDP is used, this association MAY be communica=
ted through the FEC ssrc-group semantic [RFC5576]; other mechanisms are also pos=
sible. Receivers MUST NOT attempt to interpret FEC streams for which they do=
 not have information to associate them with the corresponding payload strea=
ms.

 

 


On Oct 21, 2014, at 11:36 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

I hope I can rule my SDP logic based on standards rather than on how Chro= me implements some features.

My question was generic: if I receive the above SDP, how do I know which p= ayloads each ssrc is supposed to transport?

On 21 Oct 2014 19:57, "Peter Thatcher" <pthatcher@google.com> wrote:=

I'm not sure where it's specified, but here's where it's imp= lemented:

 

 

It only supports 2 SSRCs for a FID group.  It would ign= ore any more than that.

 

On Tue, Oct 21, 2014 at 10:40 AM, I=C3=B1aki Baz Cast= illo <ibc@aliax.net> wrote:

How is that? Where is that specified? What about if I include 3 ssrc valu= es in the ssrc-group? What is each one for?

On 21 Oct 2014 19:31, "Peter Thatcher" <pthatcher@google.com>= wrote:

345259865 is "real"

2693756249 i= s rtx

 

On Tue, Oct 21, 2014 at 9:25 AM, I=C3=B1aki Baz Casti= llo <ibc@aliax.net= > wrote:

Hi,

May I know which SSRC (345259865 or 2693756249) will be used for the
real media stream (plus RED and FEC) and which SSRC will be used for
RTX?



--------------------------
m=3Dvideo 62164 RTP/SAVPF 100 116 117 96
a=3Dmid:video
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Drtpmap:96 rtx/90000
a=3Dfmtp:96 apt=3D100
a=3Dssrc-group:FID 345259865 26= 93756249
a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 cname:e= rS7E/KHLYKTejNs
a=3Dssrc:2693756249 msid:DW= pWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91
a=3Dssrc:2693756249 mslabel= :DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
a=3Dssrc:2693756249 label:c= 0134f05-e7c2-4afd-a979-4e224de5eb91
-------------------------------




RFC 5576 does not clarify it at all:

http://tools.ietf.org/html/rfc5576#section-4.2

--------------------------------------------------
4.2.  The "ssrc-group" Media Attribute

   a=3Dssrc-group:<semantics> <ssrc-id> ...

   [..]

   The <semantics> parameter is taken from the specification= of the
   "group" attribute [RFC3388].  The initial semantic values d= efined for
   the "ssrc-group" attribute are FID (Flow Identification) [RFC33= 88]
   and FEC (Forward Error Correction) [RFC4756].  In each cas= e, the
   relationship among the grouped sources is the same as the
   relationship among corresponding sources in media streams group= ed
   using the SDP "group" attribute.
--------------------------------------------------



The referenced RFC 3388 neither clarifies it:

---------------------------------------------------
7.4 FID Semantics

   Several "m" lines grouped together using FID semantics form a m= edia
   flow.  A media agent handling a media flow that comprises s= everal "m"
   lines MUST send a copy of the media to every "m" line part of t= he
   flow as long as the codecs and the direction attribute present i= n a
   particular "m" line allow it.

   It is assumed that the application uses only one codec at a tim= e to
   encode the media produced.  This codec MAY change dynamica= lly during
   the session, but at any particular moment only one codec is in u= se.

   The application encodes the media using the current codec and c= hecks
   one by one all the "m" lines that are part of the flow.  I= f a
   particular "m" line contains the codec being used and the direc= tion
   attribute is "sendonly" or "sendrecv", a copy of the encoded me= dia is
   sent to the address/port specified in that particular media str= eam.
   If either the "m" line does not contain the codec being used or= the
   direction attribute is neither "sendonly" nor "sendrecv", nothi= ng is
   sent over this media stream.
----------------------------------------------------




So, how is the usage of ssrc-group? Where is it really defined?

Can I put more than 2 ssrc together in the same ssrc-group line?

How should the receiver interpret it?

Does a ssrc-group always mean RTX usage? Where is that specified in
the above SDP?

Does not the above SDP look a complete mixture of hacks and workarounds?
=



--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>=

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

 

 

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

= --Apple-Mail-4FB77041-A454-473D-9415-7D95A1F5A858-- From nobody Wed Oct 22 15:05:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB451AD351 for ; Wed, 22 Oct 2014 15:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pv0bSJCEMRM for ; Wed, 22 Oct 2014 15:05:48 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA721AD0C3 for ; Wed, 22 Oct 2014 15:05:48 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id E40CF9B7D516A; Wed, 22 Oct 2014 22:05:43 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s9MM5jao004437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 18:05:46 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 18:05:45 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Bernard Aboba Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw8eqhMgAAS3uCAAFkegP//weew Date: Wed, 22 Oct 2014 22:05:44 +0000 Deferred-Delivery: Wed, 22 Oct 2014 22:05:00 +0000 Message-ID: References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5ECD15US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_nluj9jVLZRDOPaVyX8GIWiMjdU Cc: "" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 22:05:51 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5ECD15US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpSRkMgNTU3NiBtYWtlcyBpdCBjbGVhciB0aGF0IHBhcnRpYWwgcmVqZWN0aW9uIGlzIG5vdCBz dXBwb3J0ZWQuDQo8UmFqdT4NClRydWUsIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1 NzYjc2VjdGlvbi04IGRpZCBzYXkgdGhhdC4gVGhhbmtzIGZvciBwb2ludGluZyBpdCBvdXQuDQpT ZWN0aW9uIDkgc2F5cyB0aGUgZm9sbG93aW5nOyB3aGljaCBzdGlsbCBzYXkgdGhlcmUgbWF5IGJl IGEgbmVlZCBmb3IgZXhwbGljaXQgc291cmNlIGRlc2NyaXB0aW9ucyBhcmUgbmVlZGVkLiBUaGUg cmVjZWl2ZXIgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGlzIFJGQyA1NTc2IHNvIGl0IHdvdWxkIGln bm9yZSB1bmtub3duIGE9c3NyYy1ncm91cCBvciBydHgvYXB4IHBheWxvYWQuIFRoZW4gaG93IGRv ZXMgaXQga25vdyB3aGljaCBzc3JjIChpdCBkb2VzIHVuZGVyc3RhbmQgYT1zc3JjIGxpbmVzKSBp cyBvcmlnaW5hbD8NCjk8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTU3NiNzZWN0aW9u LTk+LiAgQmFja3dhcmQgQ29tcGF0aWJpbGl0eQ0KICAgQWNjb3JkaW5nIHRvIHRoZSBkZWZpbml0 aW9uIG9mIFNEUCwgaW50ZXJwcmV0ZXJzIG9mIFNEUCBzZXNzaW9uDQogICBkZXNjcmlwdGlvbnMg aWdub3JlIHVua25vd24gYXR0cmlidXRlcy4gIFRodXMsIGVuZHBvaW50cyBNVVNUIGJlDQogICBw cmVwYXJlZCB0aGF0IHJlY2lwaWVudHMgb2YgdGhlaXIgUlRQIG1lZGlhIHNlc3Npb24gbWF5IG5v dA0KICAgdW5kZXJzdGFuZCB0aGVpciBleHBsaWNpdCBzb3VyY2UgZGVzY3JpcHRpb25zLCB1bmxl c3Mgc29tZSBleHRlcm5hbA0KICAgbWVjaGFuaXNtIGluZGljYXRlcyB0aGF0IHRoZXkgd2VyZSB1 bmRlcnN0b29kLiAgSW4gc29tZSBjYXNlcyAoc3VjaA0KICAgYXMgUlRQIFJldHJhbnNtaXNzaW9u IFtSRkM0NTg4PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ1ODg+XSksIHRoaXMgbWF5 IGNvbnN0cmFpbiBzb21lIGNob2ljZXMNCiAgIGFib3V0IHRoZSBiaXRzdHJlYW1zIHRoYXQgYXJl IHRyYW5zbWl0dGVkLg0KDQo8L1JhanU+DQoNCkJSDQpSYWp1DQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E5ECD15US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpo Mg0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIENo YXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglmb250LXdl aWdodDpib2xkO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSGVhZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1z dHlsZS1saW5rOiJIZWFkaW5nIDIiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SRkMgNTU3NiBtYWtlcyBpdCBjbGVhciB0aGF0IHBhcnRpYWwgcmVq ZWN0aW9uIGlzIG5vdCBzdXBwb3J0ZWQuJm5ic3A7PGJyPg0KPGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtSYWp1Jmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRydWUsDQo8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM1NTc2I3NlY3Rpb24tOCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTU3NiNzZWN0aW9uLTg8L2E+IGRpZCBzYXkgdGhhdC4gVGhhbmtzIGZvciBwb2ludGlu ZyBpdCBvdXQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2Vj dGlvbiA5IHNheXMgdGhlIGZvbGxvd2luZzsgd2hpY2ggc3RpbGwgc2F5IHRoZXJlIG1heSBiZSBh IG5lZWQgZm9yIGV4cGxpY2l0IHNvdXJjZSBkZXNjcmlwdGlvbnMgYXJlIG5lZWRlZC4gVGhlIHJl Y2VpdmVyIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhpcyBSRkMNCiA1NTc2IHNvIGl0IHdvdWxkIGln bm9yZSB1bmtub3duIGE9c3NyYy1ncm91cCBvciBydHgvYXB4IHBheWxvYWQuIFRoZW4gaG93IGRv ZXMgaXQga25vdyB3aGljaCBzc3JjIChpdCBkb2VzIHVuZGVyc3RhbmQgYT1zc3JjIGxpbmVzKSBp cyBvcmlnaW5hbD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saW5lLWhlaWdodC1hbHQ6MHB0O3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+DQo8YSBuYW1lPSJzZWN0aW9uLTkiPjwvYT48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM1NTc2I3NlY3Rpb24tOSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj45PC9zcGFuPjwvYj48L2E+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4uJm5ic3A7IEJhY2t3YXJkIENvbXBhdGliaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgQWNjb3JkaW5nIHRvIHRoZSBkZWZpbml0aW9uIG9mIFNEUCwgaW50 ZXJwcmV0ZXJzIG9mIFNEUCBzZXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgZGVzY3JpcHRpb25zIGlnbm9yZSB1bmtub3duIGF0dHJpYnV0ZXMuJm5ic3A7IFRodXMs IGVuZHBvaW50cyBNVVNUIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg cHJlcGFyZWQgdGhhdCByZWNpcGllbnRzIG9mIHRoZWlyIFJUUCBtZWRpYSBzZXNzaW9uIG1heSBu b3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB1bmRlcnN0YW5kIHRoZWly IGV4cGxpY2l0IHNvdXJjZSBkZXNjcmlwdGlvbnMsIHVubGVzcyBzb21lIGV4dGVybmFsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtIGluZGljYXRlcyB0aGF0 IHRoZXkgd2VyZSB1bmRlcnN0b29kLiZuYnNwOyBJbiBzb21lIGNhc2VzIChzdWNoPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYXMgUlRQIFJldHJhbnNtaXNzaW9uIFs8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NTg4IiB0aXRsZT0iJnF1b3Q7UlRQ IFJldHJhbnNtaXNzaW9uIFBheWxvYWQgRm9ybWF0JnF1b3Q7Ij5SRkM0NTg4PC9hPl0pLCB0aGlz IG1heSBjb25zdHJhaW4gc29tZQ0KIGNob2ljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBhYm91dCB0aGUgYml0c3RyZWFtcyB0aGF0IGFyZSB0cmFuc21pdHRlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0Oy9SYWp1Jmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UmFqdTwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E5ECD15US70UWXCHMBA02z_-- From nobody Wed Oct 22 18:22:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45421A8848 for ; Wed, 22 Oct 2014 18:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KLl4ioG_a4b for ; Wed, 22 Oct 2014 18:22:05 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6ECB1A883F for ; Wed, 22 Oct 2014 18:22:05 -0700 (PDT) Received: from [192.168.1.119] (fs5.wan.abq.citylinkwireless.net [216.243.124.18]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C14FAF2363 for ; Wed, 22 Oct 2014 18:22:04 -0700 (PDT) Message-ID: <5448583B.5090109@mozilla.com> Date: Wed, 22 Oct 2014 18:22:03 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> In-Reply-To: <54480864.4050106@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gUOmf0Sv4W4NNDfjL74Jcx9BMsc Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 01:22:07 -0000 Sergio Garcia Murillo wrote: > BTW, please, please, please, let's use the sssrc-group:FEC and send the > FEC in its own ssrc stream, so we don't have to use RED anymore.. That may be fine for video, but the added header overhead for audio is substantial (and there are a number of other problems that RED solves there, as discussed at the last meeting). From nobody Thu Oct 23 00:41:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429AE1A88F7 for ; Thu, 23 Oct 2014 00:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOvzX0GgZ-sY for ; Thu, 23 Oct 2014 00:41:25 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6AB1A88EE for ; Thu, 23 Oct 2014 00:41:24 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id em10so1179413wid.1 for ; Thu, 23 Oct 2014 00:41:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5S4gZT4fphiRJgfJsfEerl3tmfHzanlFPF+QCvzBKJs=; b=KaluKkdzFHtJISah+1v7OloOBn0j2Q3PV7OYW8ArwNK6WSCJPNyqJXwx8MoXCjw82h xCVYV2GjP80cNylEcDcz/T256HqteGv3SPsYqEZGdv6yBtw7dwYyeFDvkW+qm0zJ+dzY c4XGbzwpadkfBB6OBYF7uC7Rvta0zGAyIGd2NmEztHNanPAoK0iSMk/uDCI0/pv2mDji 0oG2pFqQmTV3ga/uvjWAqnlj1XidnQBMDh0GGe3GxO99WGoyBzY6SObM0QXd0Xo2baoC FQbWwh37sPrDJloMV73yBybPse31FM3+2wZBCdkFKxRnhWOsS1Az1PHPOuujPBrhvHET 0Q4g== X-Gm-Message-State: ALoCoQk+3gFeMVKjALQWH6Imrb/iDhYATDlC1XoNorL511MhBtvce3sPtfQpx1DV6+Kc7jumJIzQ MIME-Version: 1.0 X-Received: by 10.180.182.18 with SMTP id ea18mr10613629wic.32.1414050083204; Thu, 23 Oct 2014 00:41:23 -0700 (PDT) Received: by 10.194.158.101 with HTTP; Thu, 23 Oct 2014 00:41:23 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Date: Thu, 23 Oct 2014 09:41:23 +0200 Message-ID: From: Mohammed Raad To: Stephan Wenger Content-Type: multipart/alternative; boundary=047d7b62533ce786f90506123088 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cb03EnMKfMhfS_soK-mm4dHx3VI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 07:41:30 -0000 --047d7b62533ce786f90506123088 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephan, The relevant section in the ISO/IEC directives is: 2.14.3 Should it be revealed after publication of a document that licences under patent rights, which appear to cover items included in the document, cannot be obtained under reasonable and non-discriminatory terms and conditions, the document shall be referred back to the relevant committee for further consideration. It should be clear to participants in this discussion that not listing any patents in a type 3 declaration makes it difficult to claim that it has been "revealed after publication of a document that licences under patent rights, which appear to cover items included in the document, cannot be obtained". So, yes, ISO does have a way of dealing with such situations. MPEG, specifically, has dealt with such a situation during the development of the CDVS standard, which is a recent standard. The path chosen in that instance was to work around the known unlicensable patent. If one was to accept the idea that a type-3 declaration (i.e. there will be no licensing) without being told as to what patent the claim refers to should stop the progress of a standard, then it would be impossible to develop any standard. Regards, Mohammed On Wed, Oct 22, 2014 at 9:45 PM, Stephan Wenger wrote: > Hi, > I have to make one correction in the light of information that has > surfaced at the MPEG meeting currently ongoing in Strasbourg. (I=E2=80= =99m not at > that meeting this time, but a colleague is and she briefed me.) > Nokia has made MPEG and ISO/IEC officially aware that they are not willin= g > to license essential patents under RAND terms. For those with MPEG > document access, please see M34917. The official declaration is dated > 9/19/2014, and is not yet available from the respective databases, as ISO > is apparently changing its recordation infrastructure. > My understanding of the joint ITU/ISO/IEC patent policy is that no > standard can be issued that has a type 3 declaration against it. To the > best of my knowledge, ISO has no established procedure how to deal with > type 3 (non-RAND) declarations and still keep the standard project going. > Unlike, for example, W3C and its Patent Advisory Groups. > The declaration does not list specific patents. To the best of my > knowledge, such info is not required (only desired) for ISO and IEC > standardization work--one of the few differences in patent policy > guidelines between ITU and ISO/IEC. > Therefore, I have to row back on my previous statement of likeliness of > having an ISO number for VP8 anytime soon. At this point, I just don=E2= =80=99t > know whether, if ever, that will happen. > Regards, > Stephan > > > On 10/19/14, 6:10 PM, "Stephan Wenger" wrote: > > >Hi, > > > >On 10/19/14, 9:15 AM, "Watson Ladd" wrote: > > > >>On Sun, Oct 19, 2014 at 9:13 AM, Alexandre GOUAILLARD > >> wrote: > >>> @jonathan, > >>> > >>> while you are right and availability of 264 implementation or hardwar= e > >>> acceleration has improved, it has never been reported as a problem in > >>>the > >>> previous pool by anyone. The 264 royalties, and the VP8 IP risks were= , > >>> AFAIR, the main reasons used by individuals to justify their position= s. > >>> Today, nothing has changed with respect to those two items (even thou= gh > >>> providing open264 royalties and absorbing the license cost for some > >>> platforms might have been a set in the right direction). This is why = I > >>>think > >>> the conditions are not met for a consensus to be reached. > >> > >>But now VP8 is going through ISO, > > > >... and is is DIS ballot. Few projects in ISO get stopped at that stage= . > >To me, it=C2=B9s pretty clear that VP8 will have an ISO/IEC blessing wit= hin a > >year or two. Without substantial technical changes. Given the very > >limited participation in the relevant subgroup in MPEG, it=C2=B9s unclea= r to me > >what good that will do, though. > > > >>and the people claiming patents on > >>VP8 have had time to sue, and haven't. > > > >That=C2=B9s factually incorrect. To the best of my knowledge, what woul= d be > >factually correct is this: in two cases, companies have been sued over > >patents allegedly reading on VP8 in the context of the wider =C2=B3smart= phone > >wars=C2=B2 lawsuits, and the defendants have won non-infringement ruling= s in > >the first instance (though, last I looked, appeals were pending in both > >cases). At least one other case was settled on undisclosed terms. Some > >of these cases were widely reported in the press, others are a little bi= t > >harder to find without access to legal search tools. > > > >>That's evidence that some > >>concerns are overblown. > > > >And that depends on your viewpoint. > > > >Stephan > > > >> > >>> > >>> Alex. > >>> > >>> > >>> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba > >>> > >>> wrote: > >>>> > >>>> "And its one of the issues holding up wider adoption of the > >>>>technology" > >>>> > >>>> [BA] Specifying an MTI encoder/decoder is not sufficient for > >>>> interoperability. It is also necessary to specify the transport in > >>>>enough > >>>> detail to allow independent implementations that interoperate well > >>>>enough to > >>>> be usable in a wide variety of scenarios, including wireless network= s > >>>>where > >>>> loss is commonly experienced. > >>>> > >>>> We made the mistake of having an MTI discussion previously with not > >>>>enough > >>>> details on that subject, particularly with respect to H.264. > >>>> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > >>>> > >>>> So if we are to have the discussion again, it should occur in the > >>>>context > >>>> of detailed specifications and interoperability reports. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > >>>> > >>>> wrote: > >>>>> > >>>>> I'm in favor of taking another run at this. > >>>>> > >>>>> The working group has repeatedly said that an MTI codec is somethin= g > >>>>>we > >>>>> need to produce. And its one of the issues holding up wider adoptio= n > >>>>>of the > >>>>> technology (not the only one for sure). > >>>>> > >>>>> And things have changed since the last meeting, a year ago now > >>>>>(November > >>>>> in Vancouver). Cisco's open264 plugin shipped and now just recently > >>>>>is > >>>>> integrated into Firefox. iOS8 shipped with APIs for H264. There are > >>>>>other > >>>>> things worth noting. Will this change the minds of everyone? Surely > >>>>>not. > >>>>> Will it sway enough for us to achieve rough consensus? Maybe. IMHO = - > >>>>>worth > >>>>> finding out. > >>>>> > >>>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD > >>>>> wrote: > >>>>>> > >>>>>> +1 to not having MTI codec discussion unless some progress has bee= n > >>>>>>made > >>>>>> on VP8 at MPEG. Any news on that? I'm sharing harald's feeling th= at > >>>>>>there > >>>>>> was no change on the members position. > >>>>>> > >>>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > >>>>>> wrote: > >>>>>>> > >>>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: > >>>>>>>> > >>>>>>>> One thing we could do instead of wasting time on MTI is to > >>>>>>>>actually > >>>>>>>> make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, = so > >>>>>>>>we could > >>>>>>>> actually interoperate regardless of the codec. > >>>>>>> > >>>>>>> > >>>>>>> The big argument for an MTI is actually the one stated in > >>>>>>>-overview: It > >>>>>>> guards against interoperability failure. > >>>>>>> > >>>>>>> I would like to have an ecosystem where one can field a box, > >>>>>>>connect it > >>>>>>> to everything else, and run well for *some* level of "well" - and= I > >>>>>>>would > >>>>>>> prefer that ecosystem to be one where it's possible to field the > >>>>>>>box without > >>>>>>> making prior arrangements with anyone about licenses. > >>>>>>> > >>>>>>> This argument hasn't changed one whit since last time we discusse= d > >>>>>>>it. > >>>>>>> And I don't see much movement on the specifics of the proposals > >>>>>>>either. > >>>>>>> > >>>>>>> We'll have to interoperate well with the codecs we field. So usin= g > >>>>>>>some > >>>>>>> time to discuss draft-ietf-rtcweb-video seems to make sense. (And > >>>>>>>4.1 isn't > >>>>>>> finished either. There's one sentence that needs to be removed.) > >>>>>>> > >>>>>>> I wouldn't say I'd be happy to not discuss this in Honolulu. But > >>>>>>>I'd > >>>>>>> prefer to re-discuss based on the knowledge that some significant > >>>>>>>players > >>>>>>> have actually changed their minds. > >>>>>>> > >>>>>>> At the moment, I don't see signs that any of the poll respondents > >>>>>>>have > >>>>>>> said "I have changed my mind". > >>>>>>> > >>>>>>> Harald > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Thomson > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> On 16 October 2014 14:17, Matthew Kaufman > >>>>>>>>>> wrote: > >>>>>>>>>> And that's because something substantive has changed, or simpl= y > >>>>>>>>>> because > >>>>>>>>>> wasting the WG time on this again is more entertaining than > >>>>>>>>>>actually > >>>>>>>>>> finishing a specification that can be independently implemente= d > >>>>>>>>>>by > >>>>>>>>>> all > >>>>>>>>>> browser vendors? (A specification that we are nowhere near > >>>>>>>>>>having, > >>>>>>>>>> as far as > >>>>>>>>>> I can tell) > >>>>>>>>> > >>>>>>>>> Personally, I've found the reprieve from this fight refreshing. > >>>>>>>>>And > >>>>>>>>> it would appear that we've made some real progress as a result. > >>>>>>>>>I'd > >>>>>>>>> suggest that if we don't have new information, we continue to > >>>>>>>>>spend > >>>>>>>>> our time productively. If we can't find topics to occupy our > >>>>>>>>>meeting > >>>>>>>>> agenda time, then maybe we can free an agenda slot. > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Alex. Gouaillard, PhD, PhD, MBA > >>>>>> > >>>>>> > >>>>>>-------------------------------------------------------------------= -- > >>>>>>- > >>>>>>-------------- > >>>>>> CTO - Temasys Communications, S'pore / Mountain View > >>>>>> President - CoSMo Software, Cambridge, MA > >>>>>> > >>>>>> > >>>>>>-------------------------------------------------------------------= -- > >>>>>>- > >>>>>>-------------- > >>>>>> sg.linkedin.com/agouaillard > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> rtcweb mailing list > >>>>>> rtcweb@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Jonathan Rosenberg, Ph.D. > >>>>> jdrosen@jdrosen.net > >>>>> http://www.jdrosen.net > >>>>> > >>>>> _______________________________________________ > >>>>> rtcweb mailing list > >>>>> rtcweb@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/rtcweb > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Alex. Gouaillard, PhD, PhD, MBA > >>> > >>>----------------------------------------------------------------------= -- > >>>- > >>>----------- > >>> CTO - Temasys Communications, S'pore / Mountain View > >>> President - CoSMo Software, Cambridge, MA > >>> > >>>----------------------------------------------------------------------= -- > >>>- > >>>----------- > >>> sg.linkedin.com/agouaillard > >>> > >>> > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >>> > >> > >> > >> > >>-- > >>"Those who would give up Essential Liberty to purchase a little > >>Temporary Safety deserve neither Liberty nor Safety." > >>-- Benjamin Franklin > >> > >>_______________________________________________ > >>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 > --=20 Mohammed Raad, PhD. Partner RAADTECH CONSULTING P.O. Box 113 Warrawong NSW 2502 Australia Phone: +61 414451478 Email: mohammedsraad@raadtech.com --047d7b62533ce786f90506123088 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephan,

The relevant section in the= ISO/IEC directives is:

2.14= .3 Should it be revealed after publication of a document that licences unde= r patent=C2=A0
rights, which appear to cover items included in th= e document, cannot be obtained under=C2=A0
reasonable and non-dis= criminatory terms and conditions, the document shall be referred back=C2=A0=
to the relevant committee for further consideration.
=

It should be clear to participants in this discussion t= hat not listing any patents in a type 3 declaration makes it difficult to c= laim that it has been "revealed after publication of a document that l= icences under patent=C2=A0
rights, which appear to cover items in= cluded in the document,=C2=A0=C2=A0cannot be obtained".

=
So, yes, ISO does have a way of dealing with such situations. MP= EG, specifically, has dealt with such a situation during the development of= the CDVS standard, which is a recent standard. The path chosen in that ins= tance was to work around the known unlicensable patent.

If one was to accept the idea that a type-3 declaration (i.e. there w= ill be no licensing) without being told as to what patent the claim refers = to should stop the progress of a standard, then it would be impossible to d= evelop any standard.

Regards,
Mohammed

On Wed,= Oct 22, 2014 at 9:45 PM, Stephan Wenger <stewe@stewe.org> wro= te:
Hi,
I have to make one correction in the light of information that has
surfaced at the MPEG meeting currently ongoing in Strasbourg.=C2=A0 (I=E2= =80=99m not at
that meeting this time, but a colleague is and she briefed me.)
Nokia has made MPEG and ISO/IEC officially aware that they are not willing<= br> to license essential patents under RAND terms.=C2=A0 For those with MPEG document access, please see M34917.=C2=A0 The official declaration is dated=
9/19/2014, and is not yet available from the respective databases, as ISO is apparently changing its recordation infrastructure.
My understanding of the joint ITU/ISO/IEC patent policy is that no
standard can be issued that has a type 3 declaration against it.=C2=A0 To t= he
best of my knowledge, ISO has no established procedure how to deal with
type 3 (non-RAND) declarations and still keep the standard project going. Unlike, for example, W3C and its Patent Advisory Groups.
The declaration does not list specific patents. To the best of my
knowledge, such info is not required (only desired) for ISO and IEC
standardization work--one of the few differences in patent policy
guidelines between ITU and ISO/IEC.
Therefore, I have to row back on my previous statement of likeliness of
having an ISO number for VP8 anytime soon.=C2=A0 At this point, I just don= =E2=80=99t
know whether, if ever, that will happen.
Regards,
Stephan


On 10/19/14, 6:10 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

>Hi,
>
>On 10/19/14, 9:15 AM, "Watson Ladd" <watsonbladd@gmail.com> wrote:
>
>>On Sun, Oct 19, 2014 at 9:13 AM, Alexandre GOUAILLARD
>><agouaillard@gmail.com<= /a>> wrote:
>>> @jonathan,
>>>
>>> while you are right and availability of 264 implementation or = hardware
>>> acceleration has improved, it has never been reported as a pro= blem in
>>>the
>>> previous pool by anyone. The 264 royalties, and the VP8 IP ris= ks were,
>>> AFAIR, the main reasons used by individuals to justify their p= ositions.
>>> Today, nothing has changed with respect to those two items (ev= en though
>>> providing open264 royalties and absorbing the license cost for= some
>>> platforms might have been a set in the right direction). This = is why I
>>>think
>>> the conditions are not met for a consensus to be reached.
>>
>>But now VP8 is going through ISO,
>
>... and is is DIS ballot.=C2=A0 Few projects in ISO get stopped at that= stage.
>To me, it=C2=B9s pretty clear that VP8 will have an ISO/IEC blessing wi= thin a
>year or two.=C2=A0 Without substantial technical changes.=C2=A0 Given t= he very
>limited participation in the relevant subgroup in MPEG, it=C2=B9s uncle= ar to me
>what good that will do, though.
>
>>and the people claiming patents on
>>VP8 have had time to sue, and haven't.
>
>That=C2=B9s factually incorrect.=C2=A0 To the best of my knowledge, wha= t would be
>factually correct is this: in two cases, companies have been sued over<= br> >patents allegedly reading on VP8 in the context of the wider =C2=B3smar= tphone
>wars=C2=B2 lawsuits, and the defendants have won non-infringement rulin= gs in
>the first instance (though, last I looked, appeals were pending in both=
>cases).=C2=A0 At least one other case was settled on undisclosed terms.= =C2=A0 Some
>of these cases were widely reported in the press, others are a little b= it
>harder to find without access to legal search tools.
>
>>That's evidence that some
>>concerns are overblown.
>
>And that depends on your viewpoint.
>
>Stephan
>
>>
>>>
>>> Alex.
>>>
>>>
>>> On Sun, Oct 19, 2014 at 11:43 PM, Bernard Aboba
>>><bernard.aboba@gm= ail.com>
>>> wrote:
>>>>
>>>> "And its one of the issues holding up wider adoption = of the
>>>>technology"
>>>>
>>>> [BA] Specifying an MTI encoder/decoder is not sufficient f= or
>>>> interoperability.=C2=A0 It is also necessary to specify th= e transport in
>>>>enough
>>>> detail to allow independent implementations that interoper= ate well
>>>>enough to
>>>> be usable in a wide variety of scenarios, including wirele= ss networks
>>>>where
>>>> loss is commonly experienced.
>>>>
>>>> We made the mistake of having an MTI discussion previously= with not
>>>>enough
>>>> details on that subject, particularly with respect to H.26= 4.
>>>> draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy = at best.
>>>>
>>>> So if we are to have the discussion again, it should occur= in the
>>>>context
>>>> of detailed specifications and interoperability reports. >>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg
>>>><jdrosen@jdrosen.= net>
>>>> wrote:
>>>>>
>>>>> I'm in favor of taking another run at this.
>>>>>
>>>>> The working group has repeatedly said that an MTI code= c is something
>>>>>we
>>>>> need to produce. And its one of the issues holding up = wider adoption
>>>>>of the
>>>>> technology (not the only one for sure).
>>>>>
>>>>> And things have changed since the last meeting, a year= ago now
>>>>>(November
>>>>> in Vancouver). Cisco's open264 plugin shipped and = now just recently
>>>>>is
>>>>> integrated into Firefox. iOS8 shipped with APIs for H2= 64. There are
>>>>>other
>>>>> things worth noting. Will this change the minds of eve= ryone? Surely
>>>>>not.
>>>>> Will it sway enough for us to achieve rough consensus?= Maybe. IMHO -
>>>>>worth
>>>>> finding out.
>>>>>
>>>>> On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD<= br> >>>>> <agouailla= rd@gmail.com> wrote:
>>>>>>
>>>>>> +1 to not having MTI codec discussion unless some = progress has been
>>>>>>made
>>>>>> on VP8 at MPEG. Any news on that? I'm sharing = harald's=C2=A0 feeling that
>>>>>>there
>>>>>> was no change on the members position.
>>>>>>
>>>>>> On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand=
>>>>>> <harald= @alvestrand.no> wrote:
>>>>>>>
>>>>>>> On 10/17/2014 12:02 AM, Bernard Aboba wrote: >>>>>>>>
>>>>>>>> One thing we could do instead of wasting t= ime on MTI is to
>>>>>>>>actually
>>>>>>>> make progress on Sections 4.2 - 4.4 of dra= ft-IETF-RTCWEB-video, so
>>>>>>>>we could
>>>>>>>> actually interoperate regardless of the co= dec.
>>>>>>>
>>>>>>>
>>>>>>> The big argument for an MTI is actually the on= e stated in
>>>>>>>-overview: It
>>>>>>> guards against interoperability failure.
>>>>>>>
>>>>>>> I would like to have an ecosystem where one ca= n field a box,
>>>>>>>connect it
>>>>>>> to everything else, and run well for *some* le= vel of "well" - and I
>>>>>>>would
>>>>>>> prefer that ecosystem to be one where it's= possible to field the
>>>>>>>box without
>>>>>>> making prior arrangements with anyone about li= censes.
>>>>>>>
>>>>>>> This argument hasn't changed one whit sinc= e last time we discussed
>>>>>>>it.
>>>>>>> And I don't see much movement on the speci= fics of the proposals
>>>>>>>either.
>>>>>>>
>>>>>>> We'll have to interoperate well with the c= odecs we field. So using
>>>>>>>some
>>>>>>> time to discuss draft-ietf-rtcweb-video seems = to make sense. (And
>>>>>>>4.1 isn't
>>>>>>> finished either. There's one sentence that= needs to be removed.)
>>>>>>>
>>>>>>> I wouldn't say I'd be happy to not dis= cuss this in Honolulu. But
>>>>>>>I'd
>>>>>>> prefer to re-discuss based on the knowledge th= at some significant
>>>>>>>players
>>>>>>> have actually changed their minds.
>>>>>>>
>>>>>>> At the moment, I don't see signs that any = of the poll respondents
>>>>>>>have
>>>>>>> said "I have changed my mind".
>>>>>>>
>>>>>>> Harald
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Oct 16, 2014, at 2:28 PM, Martin Th= omson
>>>>>>>>> <martin.thomson@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 16 October 2014 14:17, Matthew = Kaufman <matthew@matthew.at>= ;
>>>>>>>>>> wrote:
>>>>>>>>>> And that's because something s= ubstantive has changed, or simply
>>>>>>>>>> because
>>>>>>>>>> wasting the WG time on this again = is more entertaining than
>>>>>>>>>>actually
>>>>>>>>>> finishing a specification that can= be independently implemented
>>>>>>>>>>by
>>>>>>>>>> all
>>>>>>>>>> browser vendors? (A specification = that we are nowhere near
>>>>>>>>>>having,
>>>>>>>>>> as far as
>>>>>>>>>> I can tell)
>>>>>>>>>
>>>>>>>>> Personally, I've found the repriev= e from this fight refreshing.
>>>>>>>>>And
>>>>>>>>> it would appear that we've made so= me real progress as a result.
>>>>>>>>>I'd
>>>>>>>>> suggest that if we don't have new = information, we continue to
>>>>>>>>>spend
>>>>>>>>> our time productively.=C2=A0 If we can= 't find topics to occupy our
>>>>>>>>>meeting
>>>>>>>>> agenda time, then maybe we can free an= agenda slot.
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> rtcweb mailing list
>>>>>>>>> rtc= web@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/= rtcweb
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> rtcweb mailing list
>>>>>>>> rtcweb@= ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcw= eb
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> rtcweb mailing list
>>>>>>> rtcweb@ietf= .org
>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alex. Gouaillard, PhD, PhD, MBA
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------= ------------------
>>>>>>-
>>>>>>--------------
>>>>>> CTO - Temasys Communications, S'pore / Mountai= n View
>>>>>> President - CoSMo Software, Cambridge, MA
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------= ------------------
>>>>>>-
>>>>>>--------------
>>>>>> sg.linkedin.com/agouaillard
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ >>>>>> rtcweb mailing list
>>>>>> rtcweb@ietf.org=
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jonathan Rosenberg, Ph.D.
>>>>> jdrosen@jdrosen= .net
>>>>> h= ttp://www.jdrosen.net
>>>>>
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>> rtcweb@ietf.org=
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Alex. Gouaillard, PhD, PhD, MBA
>>>
>>>---------------------------------------------------------------= ---------
>>>-
>>>-----------
>>> CTO - Temasys Communications, S'pore / Mountain View
>>> President - CoSMo Software, Cambridge, MA
>>>
>>>---------------------------------------------------------------= ---------
>>>-
>>>-----------
>>> sg.linkedin.com/agouaillard
>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>>
>>
>>--
>>"Those who would give up Essential Liberty to purchase a littl= e
>>Temporary Safety deserve neither=C2=A0 Liberty nor Safety." >>-- Benjamin Franklin
>>
>>_______________________________________________
>>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



--
= Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Wa= rrawong
NSW 2502 Australia
Phone: +61 414451478
Email: mohammedsraad@raadtech= .com
--047d7b62533ce786f90506123088-- From nobody Thu Oct 23 03:16:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5441A8A5E for ; Thu, 23 Oct 2014 03:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmgW7Sj0Xs0r for ; Thu, 23 Oct 2014 03:16:00 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 25DEC1A8A5A for ; Thu, 23 Oct 2014 03:15:58 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 23 Oct 2014 03:14:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,774,1406617200"; d="scan'208,217";a="623870059" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga002.jf.intel.com with ESMTP; 23 Oct 2014 03:15:57 -0700 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 23 Oct 2014 03:15:57 -0700 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.180]) by FMSMSX113.amr.corp.intel.com ([10.18.116.7]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 03:15:57 -0700 From: "Cavigioli, Chris" To: Harald Alvestrand , Bernard Aboba Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP69ySvH0vdbAWv0eULyOYAeS/S5w4ZQqA//+vamCABWG9QA== Date: Thu, 23 Oct 2014 10:15:56 +0000 Message-ID: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.108] Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD24007E125fmsmsx118amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xx0HNJkpPbeWpD2D9kk7D2REbT0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 10:16:10 -0000 --_000_E36D1A4AE0B6AA4091F1728D584A6AD24007E125fmsmsx118amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIEdTTUEgd2hpdGUgcGFwZXIgaGFzIGJlZW4gcHVibGlzaGVkLiAgRG93bmxvYWQgYSBjb3B5 IGhlcmU6ICBodHRwOi8vd3d3LmdzbWEuY29tL25ld3Nyb29tL3dlYnJ0Yy1jb2RlY3MtZHJhZnQt djEtMy8NCg0KTm90ZTogVHJhbnNjb2RpbmcgY2FuIGJlIGF2b2lkZWQgYnkgbmVnb3RpYXRpbmcg b3B0aW9uYWwgY29kZWNzIGFuZCBmaW5kaW5nIGEgbWF0Y2hpbmcgcGFpci4gIFRoZSBHU01BIHdo aXRlIHBhcGVyIGRvZXNu4oCZdCBmb2N1cyBvbiB0aGF0IGNhc2UsIGJ1dCBpbnN0ZWFkIHNwZWNp ZmljYWxseSBoaWdobGlnaHRzIHRoZSBzY2VuYXJpbyB3aGVyZSBhIHB1cmUgV2ViUlRDIGVuZHBv aW50IGlzIGNvbW11bmljYXRpbmcgd2l0aCBhIHB1cmUgM0dQUCBMVEUgVm9MVEUvVmlMVEUgSU1T IGVuZHBvaW50LCBhc3N1bWluZyBlYWNoIGVuZHBvaW50IE9OTFkgaGFzIGFjY2VzcyB0byB0aGUg TVRJIGNvZGVjcyBpbiBpdHMgcmVzcGVjdGl2ZSBkb21haW4uICBJbiB0aGF0IGNhc2UsIHRoZSBu ZXR3b3JrIGlzIHJlc3BvbnNpYmxlIHRvIHRyYW5zY29kZSBiZXR3ZWVuIChPcHVzIG9yIEcuNzEx LCA8V2ViUlRDIE1USSB2aWRlbyBjb2RlYyBUQkQ+KSBhbmQgKEFNUiBvciBBTVItV0IsIEguMjY0 KS4NCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDYXZpZ2lvbGksIENocmlzDQpTZW50OiBTdW5kYXksIE9jdG9iZXIgMTksIDIwMTQg NjoyMCBQTQ0KVG86IEhhcmFsZCBBbHZlc3RyYW5kOyBCZXJuYXJkIEFib2JhDQpDYzogcnRjd2Vi QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUGxhbiBmb3IgTVRJIHZpZGVvIGNvZGVj Pw0KDQpIYXJhbGQgc2FpZDoNCuKAnFdlIG1hZGUgdGhlIG1pc3Rha2Ugb2YgaGF2aW5nIGFuIE1U SSBkaXNjdXNzaW9uIHByZXZpb3VzbHkgd2l0aCBub3QgZW5vdWdoIGRldGFpbHMgb24gdGhhdCBz dWJqZWN04oCm4oCdDQoNCldlIGRpZG7igJl0IGhhdmUgcXVhbnRpdGF0aXZlIGRhdGEgZWFybGll ciBmb3IgYSBkYXRhLWRyaXZlbiBkZWNpc2lvbi4gIEZ1dHVyZSBXZWIg4oCTIExURSBpbnRlcm9w IGlzIGltcG9ydGFudC4gIEEgZ3JvdXAgb2YgdXMgaW4gR1NNQSBoYXZlIGJlZW4gbG9va2luZyBh dCBXZWJSVEMgaW50ZXJvcCB3aXRoIExURSAod2hlcmUgM0dQUCAvIEdTTUEgZGVmaW5lZCBJTVMt YmFzZWQgdm9pY2UvdmlkZW8vbWVzc2FnaW5nKSwgc3BlY2lmaWNhbGx5IGxvb2tpbmcgYXQgdXNl ciBleHBlcmllbmNlIGltcGFjdCBvZiBsYXRlbmN5IGludHJvZHVjZWQgYnkgYWRkZWQgaW4tbmV0 d29yayB0cmFuc2NvZGluZy4gIEdTTUEgaGFzIGFwcHJvdmVkIHRoZSB3aGl0ZXBhcGVyIGFuZCBp dCBpcyBiZWluZyBwcmVwYXJlZCBmb3IgcHVibGljIGRpc3RyaWJ1dGlvbi4NCg0KV2ViUlRDIOKA kyBMVEUgdHJhbnNjb2RpbmcgaXMgbm93IE1BTkRBVE9SWSBiZWNhdXNlIG9mIOKAnFdlYlJUQyBB dWRpbyBDb2RlYyBhbmQgUHJvY2Vzc2luZyBSZXF1aXJlbWVudHPigJ0uIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTA1LCB3aGVyZSBNVEkgYXVkaW8g Y29kZWNzIGluIFdlYlJUQyBhbmQgaW4gTFRFIGFyZSBkaXNzaW1pbGFyLiAgVGh1cywgUkVHQVJE TEVTUyBvZiB0aGUgdmlkZW8gY29kZWNzLCB0aGVyZSBpcyBhbHJlYWR5IGEgc2lnbmlmaWNhbnQg ZGVncmFkYXRpb24gaW1wb3NlZCBvbiBXZWIg4oCTIExURSBsaW5rcyBpZiBvbmx5IE1USSBjb2Rl Y3MgYXJlIHVzZWQuICBUaGUgb25seSBzeXN0ZW1zIHRvIGF2b2lkIHRoaXMgYXJlIHRob3NlIHdo aWNoIGltcGxlbWVudCBPUFRJT05BTCBhdWRpbyBjb2RlY3MgdG8gYmUgdHJhbnNjb2Rlci1mcmVl IHdpdGggTFRFLiAgVGhlIHNhbWUgY2FuIGFwcGx5IGZvciB2aWRlbyBjb2RlY3MuDQoNClRoZSBH U01BIHdoaXRlcGFwZXIgcmVmZXJzIHRvOg0KDQoxLiAgICAgUXVhbnRpdGF0aXZlIHZvaWNlLW92 ZXItTFRFIChWb0xURSkgZGVsYXkgbGltaXRzIHdlcmUgYWdyZWVkLXRvIGJ5IDNHUFAgU0E0IGlu IEF1Z3VzdCAyMDE0LiAgVG8gcGFyYXBocmFzZSwgcGVyZm9ybWFuY2Ugb2JqZWN0aXZlcyBmb3Ig bWF4aW11bSBWb0xURSBkZXZpY2UgZGVsYXlzIGluIGVycm9yIGFuZCBqaXR0ZXIgZnJlZSBjb25k aXRpb25zIGFuZCBBTVIgc3BlZWNoIGNvZGVjIG9wZXJhdGlvbiwgdGhlIHN1bSBvZiB0aGUgVUUg ZGVsYXlzIGluIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBkaXJlY3Rpb25zIChUUyArIFRSKSBzaG91 bGQgYmUg4omkIDE1MG1zLiBJZiB0aGlzIHBlcmZvcm1hbmNlIG9iamVjdGl2ZSBjYW5ub3QgYmUg bWV0LCB0aGUgc3VtIG9mIHRoZSBVRSBkZWxheXMgaW4gc2VuZGluZyBhbmQgcmVjZWl2aW5nIGRp cmVjdGlvbnMgKFRTICsgVFIpIHNoYWxsIGluIGFueSBjYXNlIGJlIOKJpCAxOTBtcy4NCg0KMi4g ICAgIE9QVVMg4oCTIEFNUiB0cmFuc2NvZGluZyBhZGRzIGFuIGFkZGl0aW9uYWwgMjExLjUgbXMg aW1wbGVtZW50YXRpb24tYWdub3N0aWMgKFRTICsgVFIpIGRlbGF5LCBpbmNsdWRpbmcgNDAgbXMg Zm9yIGppdHRlciBidWZmZXIgYW5kIDQwIG1zIGZvciBkaXNjb250aW51b3VzIHJlY2VwdGlvbiAo RFJYKS4NCg0KMy4gICAgIFRvIHB1dCB0aGVzZSBudW1iZXJzIGluIHBlcnNwZWN0aXZlLCBpdCBp cyBpbiBnZW5lcmFsIGRlc2lyYWJsZSB0byBtaW5pbWl6ZSBVRSBkZWxheXMgdG8gZW5zdXJlIGxv dyBlbm91Z2ggZW5kLXRvLWVuZCBkZWxheXMgYW5kIGhlbmNlIGEgZ29vZCBjb252ZXJzYXRpb25h bCBleHBlcmllbmNlLiAgSW5jcmVhc2luZyBkZWxheSBjYXVzZXMgcGVvcGxlIHRvIGRvdWJsZS10 YWxrIG1ha2luZyBjb252ZXJzYXRpb25zIGluY3JlYXNpbmdseSBmcnVzdHJhdGluZy4gIEd1aWRh bmNlIHRvIHN0YXkgYmVsb3cgNDAwIG1zIG1heGltdW0gb25lLXdheSBkZWxheSBpcyBmb3VuZCBp biBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjExNCBhbmQgdGhlIGNvbXB1dGF0aW9uYWwgRS1tb2Rl bCBpcyBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjEwNy4NCg0KVGhpcyBpcyBhIGNvbXBsZXgg dG9waWMgd2l0aCBtYW55IG5ldHdvcmsgZmFjdG9ycyBpbiBwbGF5LiAgTFRFIG9wZXJhdG9ycyBp biAzR1BQIHNlZWsgVUUgZGVsYXlzIChUUyArIFRSKSBhcm91bmQgMTUwIG1zLiAgQWRkaW5nIE9Q VVMg4oCTIEFNUiB0cmFuc2NvZGluZyBpbiB0aGUgbmV0d29yayBpbXBvc2VzIGFuIGFkZGl0aW9u YWwgMjExLjUgbXMgb24gdG9wIG9mIHRoYXQsIGp1c3QgZm9yIGF1ZGlvLiAgT3B0aW9uYWxseSB1 c2luZyBBTVIgaW4gV2ViUlRDLCB0aG9zZSAyMTEuNSBtcyBjYW4gYmUgZWxpbWluYXRlZCwgZGVs aXZlcmluZyBhIHN1cGVyaW9yIGVuZC11c2VyIGV4cGVyaWVuY2UuDQoNCkNPTkNMVVNJT046ICBy ZWdhcmRsZXNzIG9mIE1USSBjb2RlYyBjaG9pY2VzIGluIFdlYlJUQywgdG8gcHJvdmlkZSBhIGdv b2QgV2ViUlRDIOKAkyBMVEUgaW50ZXJvcCBleHBlcmllbmNlLCBlbWVyZ2luZyBXZWJSVEMgc3lz dGVtcyBtdXN0IGFjY29tbW9kYXRlIE1USSBjb2RlY3MgYWxyZWFkeSBkZXBsb3llZCBpbiB0aGUg TFRFIGRvbWFpbiBhbmQgaW4gbW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1zLCBuYW1lbHkgQU1SL0FN Ui1XQiBhbmQgSC4yNjQuDQoNClBPU0lUSU9OOiAgVG8gYmUgY2xlYXIsIHNldmVyYWwgSW50ZWwg U29DcyBsYXVuY2hlZCBhdCBNV0MgdGhpcyB5ZWFyIGZvciBzbWFydHBob25lcyBhbmQgdGFibGV0 cyBzdXBwb3J0IGJvdGggVlA4IGFuZCBILjI2NCBoYXJkd2FyZSBlbmNvZGUgYW5kIGRlY29kZSDi gJMgc28gSW50ZWwgaXMgY29kZWMtbmV1dHJhbCBpbiB0aGlzIE1USSBkZWJhdGUuICBBZGRpdGlv bmFsbHksIEludGVsIGhhcyBoaWdoLXBlcmZvcm1hbmNlIHNvbHV0aW9ucyBmb3IgdHJhbnNjb2Rp bmcuICBIb3dldmVyLCB3ZSB3aXNoIHRvIGluZm9ybSB0aGUgaW5kdXN0cnksIHdpdGggcXVhbnRp dGF0aXZlIGRhdGEsIGFib3V0IGltcGFjdCB0byBlbmQtdXNlciBleHBlcmllbmNlIG9mIG1hbmRh dGluZyBzdWNoIHRyYW5zY29kaW5nIHNvIElFVEYgY2FuIG1ha2UgYSBkYXRhLWRyaXZlbiBkZWNp c2lvbiBvbiB2aWRlbyBjb2RlY3MgYXMgd2VsbCBhcyByZWZsZWN0IG9uIHRoZSBpbXBhY3Qgb2Yg YWxyZWFkeSBoYXZpbmcgbWFuZGF0ZWQgdHJhbnNjb2Rpbmcgb24gdGhlIGF1ZGlvIHNpZGUuDQoN CkNocmlzIENhdmlnaW9saQ0KSW50ZWwgQ29ycCwgU3lzdGVtIEFyY2hpdGVjdHVyZSBhbmQgUGxh bm5pbmcsIFZpZGVvL011bHRpbWVkaWEsIE1vYmlsZSBhbmQgQ29tbXVuaWNhdGlvbnMgR3JvdXAg KE1DRykNCisxICg0MTUpIDI1NC00NTQ1IG1vYmlsZQ0KKzEgKDQwOCkgNjUzLTgzNDggZGVzaw0K KzEgKDQwOCkgODg0LTI0MDAgZmF4DQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50KHMpLiAgQW55IHJldmlldyBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLg0KDQpG cm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEJlcm5hcmQgQWJvYmENClNlbnQ6IFN1bmRheSwgT2N0b2JlciAxOSwgMjAxNCAyOjI5IFBNDQpU bzogSGFyYWxkIEFsdmVzdHJhbmQNCkNjOiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBQbGFuIGZvciBNVEkgdmlkZW8gY29kZWM/ DQoNCkhhcmFsZCBzYWlkOg0KDQoiQmVybmFyZCwNCg0KSSB0aGluayB0aGlzIGlzLCB0byBhIGxh cmdlIGRlZ3JlZSwgY29kZWMgaW5kZXBlbmRlbnQuDQoNCldlIGhhdmUgZGVtb25zdHJhdGVkIGlu dGVyb3BlcmFiaWxpdHkgb24gVlA4IGJldHdlZW4gRmlyZWZveCBhbmQgQ2hyb21lLCBhbmQgdXNh Z2Ugb2YgdmFyaW91cyBtZWNoYW5pc21zIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIHJlcGFp ciBvZiBwYWNrZXQgbG9zcyBiZWluZyBhcHBsaWVkIGluIGxpdmUgc2VydmljZXMuDQpTbyBpdCBj YW4ndCBiZSBhbGwgYmFkLi4uLi4iDQoNCltCQV0gIEkgYWdyZWUgdGhhdCB0aGUgbGFjayBvZiBp bnRlcm9wZXJhYmlsaXR5IGlzIGxhcmdlbHkgImNvZGVjIGluZGVwZW5kZW50IjogICB0aGF0IGlz LCBpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZGlmZmVyZW50IG1lY2hhbmlzbXMgZm9yIGNvbmdl c3Rpb24gY29udHJvbCwgcmVwYWlyLCBldGMuIHdpbGwgZXhoaWJpdCBpbnRlcm9wZXJhYmlsaXR5 IHByb2JsZW1zLCByZWdhcmRsZXNzIG9mIHRoZSBjb2RlYyBjaG9zZW4uICAgVGhlIHJlYWwgdGVz dCBmb3IgUlRDV0VCIHdpbGwgYmUgdG8gbW92ZSBiZXlvbmQgImludGVyb3BlcmFiaWxpdHkgb2Yg aW1wbGVtZW50YXRpb25zIHNoYXJpbmcgc291cmNlIGNvZGUiICB0byAiaW50ZXJvcGVyYWJpbGl0 eSBvZiBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMsIGJhc2VkIG9uIG9wZW4gc3RhbmRhcmRz Ii4NCg0KT24gU3VuLCBPY3QgMTksIDIwMTQgYXQgMTozOCBQTSwgSGFyYWxkIEFsdmVzdHJhbmQg PGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubz4+IHdyb3Rl Og0KT24gMTAvMTkvMjAxNCAwNTo0MyBQTSwgQmVybmFyZCBBYm9iYSB3cm90ZToNCiJBbmQgaXRz IG9uZSBvZiB0aGUgaXNzdWVzIGhvbGRpbmcgdXAgd2lkZXIgYWRvcHRpb24gb2YgdGhlIHRlY2hu b2xvZ3kiDQoNCltCQV0gU3BlY2lmeWluZyBhbiBNVEkgZW5jb2Rlci9kZWNvZGVyIGlzIG5vdCBz dWZmaWNpZW50IGZvciBpbnRlcm9wZXJhYmlsaXR5LiAgSXQgaXMgYWxzbyBuZWNlc3NhcnkgdG8g c3BlY2lmeSB0aGUgdHJhbnNwb3J0IGluIGVub3VnaCBkZXRhaWwgdG8gYWxsb3cgaW5kZXBlbmRl bnQgaW1wbGVtZW50YXRpb25zIHRoYXQgaW50ZXJvcGVyYXRlIHdlbGwgZW5vdWdoIHRvIGJlIHVz YWJsZSBpbiBhIHdpZGUgdmFyaWV0eSBvZiBzY2VuYXJpb3MsIGluY2x1ZGluZyB3aXJlbGVzcyBu ZXR3b3JrcyB3aGVyZSBsb3NzIGlzIGNvbW1vbmx5IGV4cGVyaWVuY2VkLg0KDQpCZXJuYXJkLA0K DQpJIHRoaW5rIHRoaXMgaXMsIHRvIGEgbGFyZ2UgZGVncmVlLCBjb2RlYyBpbmRlcGVuZGVudC4N Cg0KV2UgaGF2ZSBkZW1vbnN0cmF0ZWQgaW50ZXJvcGVyYWJpbGl0eSBvbiBWUDggYmV0d2VlbiBG aXJlZm94IGFuZCBDaHJvbWUsIGFuZCB1c2FnZSBvZiB2YXJpb3VzIG1lY2hhbmlzbXMgZm9yIGNv bmdlc3Rpb24gY29udHJvbCBhbmQgcmVwYWlyIG9mIHBhY2tldCBsb3NzIGJlaW5nIGFwcGxpZWQg aW4gbGl2ZSBzZXJ2aWNlcy4NCg0KU28gaXQgY2FuJ3QgYmUgYWxsIGJhZC4uLi4uDQoNCg0KV2Ug bWFkZSB0aGUgbWlzdGFrZSBvZiBoYXZpbmcgYW4gTVRJIGRpc2N1c3Npb24gcHJldmlvdXNseSB3 aXRoIG5vdCBlbm91Z2ggZGV0YWlscyBvbiB0aGF0IHN1YmplY3QsIHBhcnRpY3VsYXJseSB3aXRo IHJlc3BlY3QgdG8gSC4yNjQuIGRyYWZ0LWlldGYtcnRjd2ViLXZpZGVvIHNlY3Rpb25zIDQuMiAt IDQuNCByZW1haW4gc2tldGNoeSBhdCBiZXN0Lg0KDQpTbyBpZiB3ZSBhcmUgdG8gaGF2ZSB0aGUg ZGlzY3Vzc2lvbiBhZ2FpbiwgaXQgc2hvdWxkIG9jY3VyIGluIHRoZSBjb250ZXh0IG9mIGRldGFp bGVkIHNwZWNpZmljYXRpb25zIGFuZCBpbnRlcm9wZXJhYmlsaXR5IHJlcG9ydHMuDQoNCg0KDQoN Cg0KT24gU3VuLCBPY3QgMTksIDIwMTQgYXQgODoxNCBBTSwgSm9uYXRoYW4gUm9zZW5iZXJnIDxq ZHJvc2VuQGpkcm9zZW4ubmV0PG1haWx0bzpqZHJvc2VuQGpkcm9zZW4ubmV0Pj4gd3JvdGU6DQpJ J20gaW4gZmF2b3Igb2YgdGFraW5nIGFub3RoZXIgcnVuIGF0IHRoaXMuDQoNClRoZSB3b3JraW5n IGdyb3VwIGhhcyByZXBlYXRlZGx5IHNhaWQgdGhhdCBhbiBNVEkgY29kZWMgaXMgc29tZXRoaW5n IHdlIG5lZWQgdG8gcHJvZHVjZS4gQW5kIGl0cyBvbmUgb2YgdGhlIGlzc3VlcyBob2xkaW5nIHVw IHdpZGVyIGFkb3B0aW9uIG9mIHRoZSB0ZWNobm9sb2d5IChub3QgdGhlIG9ubHkgb25lIGZvciBz dXJlKS4NCg0KQW5kIHRoaW5ncyBoYXZlIGNoYW5nZWQgc2luY2UgdGhlIGxhc3QgbWVldGluZywg YSB5ZWFyIGFnbyBub3cgKE5vdmVtYmVyIGluIFZhbmNvdXZlcikuIENpc2NvJ3Mgb3BlbjI2NCBw bHVnaW4gc2hpcHBlZCBhbmQgbm93IGp1c3QgcmVjZW50bHkgaXMgaW50ZWdyYXRlZCBpbnRvIEZp cmVmb3guIGlPUzggc2hpcHBlZCB3aXRoIEFQSXMgZm9yIEgyNjQuIFRoZXJlIGFyZSBvdGhlciB0 aGluZ3Mgd29ydGggbm90aW5nLiBXaWxsIHRoaXMgY2hhbmdlIHRoZSBtaW5kcyBvZiBldmVyeW9u ZT8gU3VyZWx5IG5vdC4gV2lsbCBpdCBzd2F5IGVub3VnaCBmb3IgdXMgdG8gYWNoaWV2ZSByb3Vn aCBjb25zZW5zdXM/IE1heWJlLiBJTUhPIC0gd29ydGggZmluZGluZyBvdXQuDQoNCk9uIFNhdCwg T2N0IDE4LCAyMDE0IGF0IDU6MDggUE0sIEFsZXhhbmRyZSBHT1VBSUxMQVJEIDxhZ291YWlsbGFy ZEBnbWFpbC5jb208bWFpbHRvOmFnb3VhaWxsYXJkQGdtYWlsLmNvbT4+IHdyb3RlOg0KKzEgdG8g bm90IGhhdmluZyBNVEkgY29kZWMgZGlzY3Vzc2lvbiB1bmxlc3Mgc29tZSBwcm9ncmVzcyBoYXMg YmVlbiBtYWRlIG9uIFZQOCBhdCBNUEVHLiBBbnkgbmV3cyBvbiB0aGF0PyBJJ20gc2hhcmluZyBo YXJhbGQncyAgZmVlbGluZyB0aGF0IHRoZXJlIHdhcyBubyBjaGFuZ2Ugb24gdGhlIG1lbWJlcnMg cG9zaXRpb24uDQoNCk9uIEZyaSwgT2N0IDE3LCAyMDE0IGF0IDk6MjIgUE0sIEhhcmFsZCBBbHZl c3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8+ PiB3cm90ZToNCk9uIDEwLzE3LzIwMTQgMTI6MDIgQU0sIEJlcm5hcmQgQWJvYmEgd3JvdGU6DQpP bmUgdGhpbmcgd2UgY291bGQgZG8gaW5zdGVhZCBvZiB3YXN0aW5nIHRpbWUgb24gTVRJIGlzIHRv IGFjdHVhbGx5IG1ha2UgcHJvZ3Jlc3Mgb24gU2VjdGlvbnMgNC4yIC0gNC40IG9mIGRyYWZ0LUlF VEYtUlRDV0VCLXZpZGVvLCBzbyB3ZSBjb3VsZCBhY3R1YWxseSBpbnRlcm9wZXJhdGUgcmVnYXJk bGVzcyBvZiB0aGUgY29kZWMuDQoNClRoZSBiaWcgYXJndW1lbnQgZm9yIGFuIE1USSBpcyBhY3R1 YWxseSB0aGUgb25lIHN0YXRlZCBpbiAtb3ZlcnZpZXc6IEl0IGd1YXJkcyBhZ2FpbnN0IGludGVy b3BlcmFiaWxpdHkgZmFpbHVyZS4NCg0KSSB3b3VsZCBsaWtlIHRvIGhhdmUgYW4gZWNvc3lzdGVt IHdoZXJlIG9uZSBjYW4gZmllbGQgYSBib3gsIGNvbm5lY3QgaXQgdG8gZXZlcnl0aGluZyBlbHNl LCBhbmQgcnVuIHdlbGwgZm9yICpzb21lKiBsZXZlbCBvZiAid2VsbCIgLSBhbmQgSSB3b3VsZCBw cmVmZXIgdGhhdCBlY29zeXN0ZW0gdG8gYmUgb25lIHdoZXJlIGl0J3MgcG9zc2libGUgdG8gZmll bGQgdGhlIGJveCB3aXRob3V0IG1ha2luZyBwcmlvciBhcnJhbmdlbWVudHMgd2l0aCBhbnlvbmUg YWJvdXQgbGljZW5zZXMuDQoNClRoaXMgYXJndW1lbnQgaGFzbid0IGNoYW5nZWQgb25lIHdoaXQg c2luY2UgbGFzdCB0aW1lIHdlIGRpc2N1c3NlZCBpdC4gQW5kIEkgZG9uJ3Qgc2VlIG11Y2ggbW92 ZW1lbnQgb24gdGhlIHNwZWNpZmljcyBvZiB0aGUgcHJvcG9zYWxzIGVpdGhlci4NCg0KV2UnbGwg aGF2ZSB0byBpbnRlcm9wZXJhdGUgd2VsbCB3aXRoIHRoZSBjb2RlY3Mgd2UgZmllbGQuIFNvIHVz aW5nIHNvbWUgdGltZSB0byBkaXNjdXNzIGRyYWZ0LWlldGYtcnRjd2ViLXZpZGVvIHNlZW1zIHRv IG1ha2Ugc2Vuc2UuIChBbmQgNC4xIGlzbid0IGZpbmlzaGVkIGVpdGhlci4gVGhlcmUncyBvbmUg c2VudGVuY2UgdGhhdCBuZWVkcyB0byBiZSByZW1vdmVkLikNCg0KSSB3b3VsZG4ndCBzYXkgSSdk IGJlIGhhcHB5IHRvIG5vdCBkaXNjdXNzIHRoaXMgaW4gSG9ub2x1bHUuIEJ1dCBJJ2QgcHJlZmVy IHRvIHJlLWRpc2N1c3MgYmFzZWQgb24gdGhlIGtub3dsZWRnZSB0aGF0IHNvbWUgc2lnbmlmaWNh bnQgcGxheWVycyBoYXZlIGFjdHVhbGx5IGNoYW5nZWQgdGhlaXIgbWluZHMuDQoNCkF0IHRoZSBt b21lbnQsIEkgZG9uJ3Qgc2VlIHNpZ25zIHRoYXQgYW55IG9mIHRoZSBwb2xsIHJlc3BvbmRlbnRz IGhhdmUgc2FpZCAiSSBoYXZlIGNoYW5nZWQgbXkgbWluZCIuDQoNCkhhcmFsZA0KDQoNCk9uIE9j dCAxNiwgMjAxNCwgYXQgMjoyOCBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdt YWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpPbiAxNiBP Y3RvYmVyIDIwMTQgMTQ6MTcsIE1hdHRoZXcgS2F1Zm1hbiA8bWF0dGhld0BtYXR0aGV3LmF0PG1h aWx0bzptYXR0aGV3QG1hdHRoZXcuYXQ+PiB3cm90ZToNCkFuZCB0aGF0J3MgYmVjYXVzZSBzb21l dGhpbmcgc3Vic3RhbnRpdmUgaGFzIGNoYW5nZWQsIG9yIHNpbXBseSBiZWNhdXNlDQp3YXN0aW5n IHRoZSBXRyB0aW1lIG9uIHRoaXMgYWdhaW4gaXMgbW9yZSBlbnRlcnRhaW5pbmcgdGhhbiBhY3R1 YWxseQ0KZmluaXNoaW5nIGEgc3BlY2lmaWNhdGlvbiB0aGF0IGNhbiBiZSBpbmRlcGVuZGVudGx5 IGltcGxlbWVudGVkIGJ5IGFsbA0KYnJvd3NlciB2ZW5kb3JzPyAoQSBzcGVjaWZpY2F0aW9uIHRo YXQgd2UgYXJlIG5vd2hlcmUgbmVhciBoYXZpbmcsIGFzIGZhciBhcw0KSSBjYW4gdGVsbCkNClBl cnNvbmFsbHksIEkndmUgZm91bmQgdGhlIHJlcHJpZXZlIGZyb20gdGhpcyBmaWdodCByZWZyZXNo aW5nLiAgQW5kDQppdCB3b3VsZCBhcHBlYXIgdGhhdCB3ZSd2ZSBtYWRlIHNvbWUgcmVhbCBwcm9n cmVzcyBhcyBhIHJlc3VsdC4gIEknZA0Kc3VnZ2VzdCB0aGF0IGlmIHdlIGRvbid0IGhhdmUgbmV3 IGluZm9ybWF0aW9uLCB3ZSBjb250aW51ZSB0byBzcGVuZA0Kb3VyIHRpbWUgcHJvZHVjdGl2ZWx5 LiAgSWYgd2UgY2FuJ3QgZmluZCB0b3BpY3MgdG8gb2NjdXB5IG91ciBtZWV0aW5nDQphZ2VuZGEg dGltZSwgdGhlbiBtYXliZSB3ZSBjYW4gZnJlZSBhbiBhZ2VuZGEgc2xvdC4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxp c3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViDQoNCg0KDQotLQ0KQWxleC4gR291YWlsbGFyZCwgUGhELCBQaEQsIE1CQQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDVE8gLSBUZW1hc3lzIENvbW11bmljYXRpb25zLCBTJ3Bv cmUgLyBNb3VudGFpbiBWaWV3DQpQcmVzaWRlbnQgLSBDb1NNbyBTb2Z0d2FyZSwgQ2FtYnJpZGdl LCBNQQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpzZy5saW5rZWRpbi5jb20vYWdvdWFp bGxhcmQ8aHR0cDovL3NnLmxpbmtlZGluLmNvbS9hZ291YWlsbGFyZD4NCsK3DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBs aXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQotLQ0KSm9uYXRoYW4gUm9z ZW5iZXJnLCBQaC5ELg0KamRyb3NlbkBqZHJvc2VuLm5ldDxtYWlsdG86amRyb3NlbkBqZHJvc2Vu Lm5ldD4NCmh0dHA6Ly93d3cuamRyb3Nlbi5uZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRm Lm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWINCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCg0KcnRjd2ViQGlldGYub3Jn PG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRjd2ViDQoNCg0KLS0NCg0KU3VydmVpbGxhbmNlIGlzIHBlcnZhc2l2ZS4gR28g RGFyay4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_E36D1A4AE0B6AA4091F1728D584A6AD24007E125fmsmsx118amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTHVj aWRhIENvbnNvbGUiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDQgNSA0IDIgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTppbmhlcml0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmhvZW56 Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjQ4OTA5NzYyNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4MjYz NDE3MzI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjY4MDg2 MTgwNjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEz NDk0Nzg3MiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgR1NNQSB3aGl0ZSBwYXBlciBoYXMgYmVlbiBw dWJsaXNoZWQuJm5ic3A7IERvd25sb2FkIGEgY29weSBoZXJlOiZuYnNwOw0KPGEgaHJlZj0iaHR0 cDovL3d3dy5nc21hLmNvbS9uZXdzcm9vbS93ZWJydGMtY29kZWNzLWRyYWZ0LXYxLTMvIj5odHRw Oi8vd3d3LmdzbWEuY29tL25ld3Nyb29tL3dlYnJ0Yy1jb2RlY3MtZHJhZnQtdjEtMy88L2E+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Tm90ZTogVHJhbnNjb2RpbmcgY2FuIGJlIGF2b2lkZWQgYnkgbmVnb3RpYXRpbmcgb3B0 aW9uYWwgY29kZWNzIGFuZCBmaW5kaW5nIGEgbWF0Y2hpbmcgcGFpci4mbmJzcDsgVGhlIEdTTUEg d2hpdGUgcGFwZXIgZG9lc27igJl0IGZvY3VzIG9uIHRoYXQgY2FzZSwgYnV0IGluc3RlYWQgc3Bl Y2lmaWNhbGx5DQogaGlnaGxpZ2h0cyB0aGUgc2NlbmFyaW8gd2hlcmUgYSBwdXJlIFdlYlJUQyBl bmRwb2ludCBpcyBjb21tdW5pY2F0aW5nIHdpdGggYSBwdXJlIDNHUFAgTFRFIFZvTFRFL1ZpTFRF IElNUyBlbmRwb2ludCwgYXNzdW1pbmcgZWFjaCBlbmRwb2ludCBPTkxZIGhhcyBhY2Nlc3MgdG8g dGhlIE1USSBjb2RlY3MgaW4gaXRzIHJlc3BlY3RpdmUgZG9tYWluLiZuYnNwOyBJbiB0aGF0IGNh c2UsIHRoZSBuZXR3b3JrIGlzIHJlc3BvbnNpYmxlIHRvIHRyYW5zY29kZSBiZXR3ZWVuDQogKE9w dXMgb3IgRy43MTEsICZsdDtXZWJSVEMgTVRJIHZpZGVvIGNvZGVjIFRCRCZndDspIGFuZCAoQU1S IG9yIEFNUi1XQiwgSC4yNjQpLiZuYnNwOyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2F2aWdp b2xpLCBDaHJpczxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE9jdG9iZXIgMTksIDIwMTQgNjoy MCBQTTxicj4NCjxiPlRvOjwvYj4gSGFyYWxkIEFsdmVzdHJhbmQ7IEJlcm5hcmQgQWJvYmE8YnI+ DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0 Y3dlYl0gUGxhbiBmb3IgTVRJIHZpZGVvIGNvZGVjPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGFyYWxkIHNhaWQ6Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj7igJxXZSBtYWRlIHRoZSBtaXN0YWtlIG9mIGhhdmluZyBhbiBNVEkgZGlz Y3Vzc2lvbiBwcmV2aW91c2x5IHdpdGggbm90IGVub3VnaCBkZXRhaWxzIG9uIHRoYXQgc3ViamVj dOKApuKAnTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldl IGRpZG7igJl0IGhhdmUgcXVhbnRpdGF0aXZlIGRhdGEgZWFybGllciBmb3IgYSBkYXRhLWRyaXZl biBkZWNpc2lvbi4mbmJzcDsgRnV0dXJlIFdlYiDigJMgTFRFIGludGVyb3AgaXMgaW1wb3J0YW50 LiZuYnNwOyBBIGdyb3VwIG9mIHVzIGluIEdTTUEgaGF2ZSBiZWVuIGxvb2tpbmcgYXQgV2ViUlRD DQogaW50ZXJvcCB3aXRoIExURSAod2hlcmUgM0dQUCAvIEdTTUEgZGVmaW5lZCBJTVMtYmFzZWQg dm9pY2UvdmlkZW8vbWVzc2FnaW5nKSwgc3BlY2lmaWNhbGx5IGxvb2tpbmcgYXQgdXNlciBleHBl cmllbmNlIGltcGFjdCBvZiBsYXRlbmN5IGludHJvZHVjZWQgYnkgYWRkZWQgaW4tbmV0d29yayB0 cmFuc2NvZGluZy4mbmJzcDsgR1NNQSBoYXMgYXBwcm92ZWQgdGhlIHdoaXRlcGFwZXIgYW5kIGl0 IGlzIGJlaW5nIHByZXBhcmVkIGZvciBwdWJsaWMgZGlzdHJpYnV0aW9uLiZuYnNwOw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PldlYlJUQyDigJMgTFRFIHRyYW5zY29kaW5nIGlzIG5vdyBNQU5EQVRPUlkgYmVjYXVzZSBvZiDi gJxXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nlc3NpbmcgUmVxdWlyZW1lbnRz4oCdLg0KPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8t MDUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTA1 PC9hPiwgd2hlcmUgTVRJIGF1ZGlvIGNvZGVjcyBpbiBXZWJSVEMgYW5kIGluIExURSBhcmUgZGlz c2ltaWxhci4mbmJzcDsgVGh1cywgUkVHQVJETEVTUyBvZiB0aGUgdmlkZW8gY29kZWNzLCB0aGVy ZSBpcyBhbHJlYWR5IGEgc2lnbmlmaWNhbnQgZGVncmFkYXRpb24NCiBpbXBvc2VkIG9uIFdlYiDi gJMgTFRFIGxpbmtzIGlmIG9ubHkgTVRJIGNvZGVjcyBhcmUgdXNlZC4mbmJzcDsgVGhlIG9ubHkg c3lzdGVtcyB0byBhdm9pZCB0aGlzIGFyZSB0aG9zZSB3aGljaCBpbXBsZW1lbnQgT1BUSU9OQUwg YXVkaW8gY29kZWNzIHRvIGJlIHRyYW5zY29kZXItZnJlZSB3aXRoIExURS4mbmJzcDsgVGhlIHNh bWUgY2FuIGFwcGx5IGZvciB2aWRlbyBjb2RlY3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBHU01BIHdoaXRlcGFwZXIg cmVmZXJzIHRvOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlF1YW50aXRhdGl2ZSB2b2ljZS1vdmVyLUxURSAoVm9MVEUpIGRlbGF5 IGxpbWl0cyB3ZXJlIGFncmVlZC10byBieSAzR1BQIFNBNCBpbiBBdWd1c3QgMjAxNC4mbmJzcDsg VG8gcGFyYXBocmFzZSwgcGVyZm9ybWFuY2Ugb2JqZWN0aXZlcyBmb3IgbWF4aW11bSBWb0xURQ0K IGRldmljZSBkZWxheXMgaW4gZXJyb3IgYW5kIGppdHRlciBmcmVlIGNvbmRpdGlvbnMgYW5kIEFN UiBzcGVlY2ggY29kZWMgb3BlcmF0aW9uLCB0aGUgc3VtIG9mIHRoZSBVRSBkZWxheXMgaW4gc2Vu ZGluZyBhbmQgcmVjZWl2aW5nIGRpcmVjdGlvbnMgKFQ8c3ViPlM8L3N1Yj4gJiM0MzsgVDxzdWI+ Ujwvc3ViPikgc2hvdWxkIGJlIOKJpCAxNTBtcy4gSWYgdGhpcyBwZXJmb3JtYW5jZSBvYmplY3Rp dmUgY2Fubm90IGJlIG1ldCwgdGhlIHN1bSBvZiB0aGUgVUUNCiBkZWxheXMgaW4gc2VuZGluZyBh bmQgcmVjZWl2aW5nIGRpcmVjdGlvbnMgKFQ8c3ViPlM8L3N1Yj4gJiM0MzsgVDxzdWI+Ujwvc3Vi Pikgc2hhbGwgaW4gYW55IGNhc2UgYmUg4omkIDE5MG1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9QVVMg4oCTIEFNUiB0cmFu c2NvZGluZyBhZGRzIGFuIGFkZGl0aW9uYWwgMjExLjUgbXMgaW1wbGVtZW50YXRpb24tYWdub3N0 aWMgKFQ8c3ViPlM8L3N1Yj4gJiM0MzsgVDxzdWI+Ujwvc3ViPikgZGVsYXksIGluY2x1ZGluZyA0 MCBtcyBmb3Igaml0dGVyIGJ1ZmZlcg0KIGFuZCA0MCBtcyBmb3IgZGlzY29udGludW91cyByZWNl cHRpb24gKERSWCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VG8gcHV0IHRoZXNlIG51bWJlcnMgaW4gcGVyc3BlY3RpdmUsIGl0 IGlzIGluIGdlbmVyYWwgZGVzaXJhYmxlIHRvIG1pbmltaXplIFVFIGRlbGF5cyB0byBlbnN1cmUg bG93IGVub3VnaCBlbmQtdG8tZW5kIGRlbGF5cyBhbmQgaGVuY2UgYSBnb29kIGNvbnZlcnNhdGlv bmFsDQogZXhwZXJpZW5jZS4mbmJzcDsgSW5jcmVhc2luZyBkZWxheSBjYXVzZXMgcGVvcGxlIHRv IGRvdWJsZS10YWxrIG1ha2luZyBjb252ZXJzYXRpb25zIGluY3JlYXNpbmdseSBmcnVzdHJhdGlu Zy4mbmJzcDsgR3VpZGFuY2UgdG8gc3RheSBiZWxvdyA0MDAgbXMgbWF4aW11bSBvbmUtd2F5IGRl bGF5IGlzIGZvdW5kIGluIElUVS1UIFJlY29tbWVuZGF0aW9uIEcuMTE0IGFuZCB0aGUgY29tcHV0 YXRpb25hbCBFLW1vZGVsIGlzIGluIElUVS1UIFJlY29tbWVuZGF0aW9uIEcuMTA3LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGlzIGlzIGEgY29tcGxleCB0b3BpYyB3aXRoIG1hbnkgbmV0d29yayBmYWN0b3JzIGluIHBsYXku Jm5ic3A7IExURSBvcGVyYXRvcnMgaW4gM0dQUCBzZWVrIFVFIGRlbGF5cyAoVDxzdWI+Uzwvc3Vi PiAmIzQzOyBUPHN1Yj5SPC9zdWI+KSBhcm91bmQgMTUwIG1zLiZuYnNwOyBBZGRpbmcgT1BVUyDi gJMNCiBBTVIgdHJhbnNjb2RpbmcgaW4gdGhlIG5ldHdvcmsgaW1wb3NlcyBhbiBhZGRpdGlvbmFs IDIxMS41IG1zIG9uIHRvcCBvZiB0aGF0LCBqdXN0IGZvciBhdWRpby4mbmJzcDsgT3B0aW9uYWxs eSB1c2luZyBBTVIgaW4gV2ViUlRDLCB0aG9zZSAyMTEuNSBtcyBjYW4gYmUgZWxpbWluYXRlZCwg ZGVsaXZlcmluZyBhIHN1cGVyaW9yIGVuZC11c2VyIGV4cGVyaWVuY2UuJm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Q09OQ0xVU0lPTjogJm5ic3A7cmVnYXJkbGVzcyBvZiBNVEkgY29kZWMgY2hvaWNlcyBpbiBXZWJS VEMsIHRvIHByb3ZpZGUgYSBnb29kIFdlYlJUQyDigJMgTFRFIGludGVyb3AgZXhwZXJpZW5jZSwg ZW1lcmdpbmcgV2ViUlRDIHN5c3RlbXMgbXVzdCBhY2NvbW1vZGF0ZSBNVEkgY29kZWNzDQogYWxy ZWFkeSBkZXBsb3llZCBpbiB0aGUgTFRFIGRvbWFpbiBhbmQgaW4gbW9iaWxlIG9wZXJhdGluZyBz eXN0ZW1zLCBuYW1lbHkgQU1SL0FNUi1XQiBhbmQgSC4yNjQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBPU0lUSU9OOiZuYnNw OyBUbyBiZSBjbGVhciwgc2V2ZXJhbCBJbnRlbCBTb0NzIGxhdW5jaGVkIGF0IE1XQyB0aGlzIHll YXIgZm9yIHNtYXJ0cGhvbmVzIGFuZCB0YWJsZXRzIHN1cHBvcnQgYm90aCBWUDggYW5kIEguMjY0 IGhhcmR3YXJlIGVuY29kZSBhbmQgZGVjb2RlIOKAkyBzbyBJbnRlbA0KIGlzIGNvZGVjLW5ldXRy YWwgaW4gdGhpcyBNVEkgZGViYXRlLiZuYnNwOyBBZGRpdGlvbmFsbHksIEludGVsIGhhcyBoaWdo LXBlcmZvcm1hbmNlIHNvbHV0aW9ucyBmb3IgdHJhbnNjb2RpbmcuJm5ic3A7IEhvd2V2ZXIsIHdl IHdpc2ggdG8gaW5mb3JtIHRoZSBpbmR1c3RyeSwgd2l0aCBxdWFudGl0YXRpdmUgZGF0YSwgYWJv dXQgaW1wYWN0IHRvIGVuZC11c2VyIGV4cGVyaWVuY2Ugb2YgbWFuZGF0aW5nIHN1Y2ggdHJhbnNj b2Rpbmcgc28gSUVURiBjYW4gbWFrZSBhDQogZGF0YS1kcml2ZW4gZGVjaXNpb24gb24gdmlkZW8g Y29kZWNzIGFzIHdlbGwgYXMgcmVmbGVjdCBvbiB0aGUgaW1wYWN0IG9mIGFscmVhZHkgaGF2aW5n IG1hbmRhdGVkIHRyYW5zY29kaW5nIG9uIHRoZSBhdWRpbyBzaWRlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNocmlzIENhdmlnaW9saTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkludGVsIENvcnAsDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwNzBDMCI+U3lzdGVtIEFyY2hpdGVjdHVyZSBhbmQgUGxhbm5pbmc8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LCBWaWRlby9NdWx0aW1lZGlhLCBNb2Jp bGUgYW5kIENvbW11bmljYXRpb25zIEdyb3VwIChNQ0cpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+JiM0MzsxICg0MTUpIDI1NC00NTQ1IG1vYmlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiYjNDM7MSAoNDA4KSA2NTMtODM0OCBkZXNrPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+JiM0MzsxICg0MDgpIDg4NC0yNDAwIGZheDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmdyYXki PlRoaXMgZS1tYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRl cmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuJm5ic3A7 IEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLg0KIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250 YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5CZXJuYXJkIEFib2JhPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgT2N0 b2JlciAxOSwgMjAxNCAyOjI5IFBNPGJyPg0KPGI+VG86PC9iPiBIYXJhbGQgQWx2ZXN0cmFuZDxi cj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUGxhbiBmb3IgTVRJ IHZpZGVvIGNvZGVjPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhcmFs ZCBzYWlkOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+JnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmVybmFyZCw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KSSB0aGluayB0aGlz IGlzLCB0byBhIGxhcmdlIGRlZ3JlZSwgY29kZWMgaW5kZXBlbmRlbnQuPGJyPg0KPGJyPg0KV2Ug aGF2ZSBkZW1vbnN0cmF0ZWQgaW50ZXJvcGVyYWJpbGl0eSBvbiBWUDggYmV0d2VlbiBGaXJlZm94 IGFuZCBDaHJvbWUsIGFuZCB1c2FnZSBvZiB2YXJpb3VzIG1lY2hhbmlzbXMgZm9yIGNvbmdlc3Rp b24gY29udHJvbCBhbmQgcmVwYWlyIG9mIHBhY2tldCBsb3NzIGJlaW5nIGFwcGxpZWQgaW4gbGl2 ZSBzZXJ2aWNlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U28gaXQgY2FuJ3QgYmUgYWxsIGJhZC4u Li4uPC9zcGFuPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5bQkFdICZuYnNwO0kgYWdyZWUgdGhhdCB0aGUgbGFjayBvZiBpbnRlcm9w ZXJhYmlsaXR5IGlzIGxhcmdlbHkgJnF1b3Q7Y29kZWMgaW5kZXBlbmRlbnQmcXVvdDs6ICZuYnNw OyB0aGF0IGlzLCBpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZGlmZmVyZW50IG1lY2hhbmlzbXMg Zm9yIGNvbmdlc3Rpb24gY29udHJvbCwgcmVwYWlyLCBldGMuIHdpbGwgZXhoaWJpdCBpbnRlcm9w ZXJhYmlsaXR5IHByb2JsZW1zLCByZWdhcmRsZXNzIG9mIHRoZSBjb2RlYw0KIGNob3Nlbi4gJm5i c3A7IFRoZSByZWFsIHRlc3QgZm9yIFJUQ1dFQiB3aWxsIGJlIHRvIG1vdmUgYmV5b25kICZxdW90 O2ludGVyb3BlcmFiaWxpdHkgb2YgaW1wbGVtZW50YXRpb25zIHNoYXJpbmcgc291cmNlIGNvZGUm cXVvdDsgJm5ic3A7dG8gJnF1b3Q7aW50ZXJvcGVyYWJpbGl0eSBvZiBpbmRlcGVuZGVudCBpbXBs ZW1lbnRhdGlvbnMsIGJhc2VkIG9uIG9wZW4gc3RhbmRhcmRzJnF1b3Q7LiAmbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g U3VuLCBPY3QgMTksIDIwMTQgYXQgMTozOCBQTSwgSGFyYWxkIEFsdmVzdHJhbmQgJmx0OzxhIGhy ZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyIgdGFyZ2V0PSJfYmxhbmsiPmhhcmFsZEBh bHZlc3RyYW5kLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEwLzE5LzIwMTQgMDU6NDMgUE0sIEJlcm5hcmQgQWJv YmEgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZxdW90O0FuZCBpdHMgb25lIG9mIHRoZSBpc3N1ZXMgaG9sZGluZyB1cCB3aWRlciBh ZG9wdGlvbiBvZiB0aGUgdGVjaG5vbG9neSZxdW90Ow0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQkFdIFNwZWNpZnlpbmcgYW4gTVRJIGVuY29kZXIvZGVj b2RlciBpcyBub3Qgc3VmZmljaWVudCBmb3IgaW50ZXJvcGVyYWJpbGl0eS4mbmJzcDsgSXQgaXMg YWxzbyBuZWNlc3NhcnkgdG8gc3BlY2lmeSB0aGUgdHJhbnNwb3J0IGluIGVub3VnaCBkZXRhaWwg dG8gYWxsb3cgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIHRoYXQgaW50ZXJvcGVyYXRlIHdl bGwgZW5vdWdoIHRvIGJlIHVzYWJsZSBpbiBhIHdpZGUgdmFyaWV0eQ0KIG9mIHNjZW5hcmlvcywg aW5jbHVkaW5nIHdpcmVsZXNzIG5ldHdvcmtzIHdoZXJlIGxvc3MgaXMgY29tbW9ubHkgZXhwZXJp ZW5jZWQuJm5ic3A7IDxvOnA+DQo8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQmVybmFyZCw8YnI+DQo8YnI+DQpJIHRo aW5rIHRoaXMgaXMsIHRvIGEgbGFyZ2UgZGVncmVlLCBjb2RlYyBpbmRlcGVuZGVudC48YnI+DQo8 YnI+DQpXZSBoYXZlIGRlbW9uc3RyYXRlZCBpbnRlcm9wZXJhYmlsaXR5IG9uIFZQOCBiZXR3ZWVu IEZpcmVmb3ggYW5kIENocm9tZSwgYW5kIHVzYWdlIG9mIHZhcmlvdXMgbWVjaGFuaXNtcyBmb3Ig Y29uZ2VzdGlvbiBjb250cm9sIGFuZCByZXBhaXIgb2YgcGFja2V0IGxvc3MgYmVpbmcgYXBwbGll ZCBpbiBsaXZlIHNlcnZpY2VzLjxicj4NCjxicj4NClNvIGl0IGNhbid0IGJlIGFsbCBiYWQuLi4u LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIG1hZGUgdGhlIG1pc3Rha2Ugb2YgaGF2aW5n IGFuIE1USSBkaXNjdXNzaW9uIHByZXZpb3VzbHkgd2l0aCBub3QgZW5vdWdoIGRldGFpbHMgb24g dGhhdCBzdWJqZWN0LCBwYXJ0aWN1bGFybHkgd2l0aCByZXNwZWN0IHRvIEguMjY0LiBkcmFmdC1p ZXRmLXJ0Y3dlYi12aWRlbyBzZWN0aW9ucyA0LjIgLSA0LjQgcmVtYWluIHNrZXRjaHkgYXQgYmVz dC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNvIGlmIHdlIGFyZSB0byBoYXZlIHRoZSBkaXNjdXNzaW9uIGFnYWluLCBpdCBzaG91 bGQgb2NjdXIgaW4gdGhlIGNvbnRleHQgb2YgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbnMgYW5kIGlu dGVyb3BlcmFiaWxpdHkgcmVwb3J0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE9jdCAxOSwgMjAxNCBhdCA4OjE0 IEFNLCBKb25hdGhhbiBSb3NlbmJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpqZHJvc2VuQGpkcm9z ZW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+amRyb3NlbkBqZHJvc2VuLm5ldDwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBpbiBmYXZv ciBvZiB0YWtpbmcgYW5vdGhlciBydW4gYXQgdGhpcy4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgd29ya2luZyBncm91cCBoYXMgcmVwZWF0ZWRseSBz YWlkIHRoYXQgYW4gTVRJIGNvZGVjIGlzIHNvbWV0aGluZyB3ZSBuZWVkIHRvIHByb2R1Y2UuIEFu ZCBpdHMgb25lIG9mIHRoZSBpc3N1ZXMgaG9sZGluZyB1cCB3aWRlciBhZG9wdGlvbiBvZiB0aGUg dGVjaG5vbG9neSAobm90IHRoZSBvbmx5IG9uZSBmb3Igc3VyZSkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB0aGluZ3MgaGF2ZSBjaGFu Z2VkIHNpbmNlIHRoZSBsYXN0IG1lZXRpbmcsIGEgeWVhciBhZ28gbm93IChOb3ZlbWJlciBpbiBW YW5jb3V2ZXIpLiBDaXNjbydzIG9wZW4yNjQgcGx1Z2luIHNoaXBwZWQgYW5kIG5vdyBqdXN0IHJl Y2VudGx5IGlzIGludGVncmF0ZWQgaW50byBGaXJlZm94LiBpT1M4IHNoaXBwZWQgd2l0aCBBUElz IGZvciBIMjY0LiBUaGVyZSBhcmUgb3RoZXIgdGhpbmdzIHdvcnRoIG5vdGluZy4NCiBXaWxsIHRo aXMgY2hhbmdlIHRoZSBtaW5kcyBvZiBldmVyeW9uZT8gU3VyZWx5IG5vdC4gV2lsbCBpdCBzd2F5 IGVub3VnaCBmb3IgdXMgdG8gYWNoaWV2ZSByb3VnaCBjb25zZW5zdXM/IE1heWJlLiBJTUhPIC0g d29ydGggZmluZGluZyBvdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBPY3QgMTgsIDIwMTQgYXQgNTow OCBQTSwgQWxleGFuZHJlIEdPVUFJTExBUkQgJmx0OzxhIGhyZWY9Im1haWx0bzphZ291YWlsbGFy ZEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hZ291YWlsbGFyZEBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQz OzEgdG8gbm90IGhhdmluZyBNVEkgY29kZWMgZGlzY3Vzc2lvbiB1bmxlc3Mgc29tZSBwcm9ncmVz cyBoYXMgYmVlbiBtYWRlIG9uIFZQOCBhdCBNUEVHLiZuYnNwO0FueSBuZXdzIG9uIHRoYXQ/IEkn bSBzaGFyaW5nIGhhcmFsZCdzICZuYnNwO2ZlZWxpbmcgdGhhdCB0aGVyZSB3YXMgbm8gY2hhbmdl IG9uIHRoZSBtZW1iZXJzIHBvc2l0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE9jdCAxNywgMjAxNCBh dCA5OjIyIFBNLCBIYXJhbGQgQWx2ZXN0cmFuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhcmFsZEBh bHZlc3RyYW5kLm5vIiB0YXJnZXQ9Il9ibGFuayI+aGFyYWxkQGFsdmVzdHJhbmQubm88L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEwLzE3LzIw MTQgMTI6MDIgQU0sIEJlcm5hcmQgQWJvYmEgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbmUgdGhpbmcgd2UgY291bGQgZG8gaW5zdGVhZCBvZiB3YXN0aW5nIHRp bWUgb24gTVRJIGlzIHRvIGFjdHVhbGx5IG1ha2UgcHJvZ3Jlc3Mgb24gU2VjdGlvbnMgNC4yIC0g NC40IG9mIGRyYWZ0LUlFVEYtUlRDV0VCLXZpZGVvLCBzbyB3ZSBjb3VsZCBhY3R1YWxseSBpbnRl cm9wZXJhdGUgcmVnYXJkbGVzcyBvZiB0aGUgY29kZWMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpUaGUgYmlnIGFyZ3VtZW50IGZvciBhbiBNVEkgaXMgYWN0dWFs bHkgdGhlIG9uZSBzdGF0ZWQgaW4gLW92ZXJ2aWV3OiBJdCBndWFyZHMgYWdhaW5zdCBpbnRlcm9w ZXJhYmlsaXR5IGZhaWx1cmUuPGJyPg0KPGJyPg0KSSB3b3VsZCBsaWtlIHRvIGhhdmUgYW4gZWNv c3lzdGVtIHdoZXJlIG9uZSBjYW4gZmllbGQgYSBib3gsIGNvbm5lY3QgaXQgdG8gZXZlcnl0aGlu ZyBlbHNlLCBhbmQgcnVuIHdlbGwgZm9yICpzb21lKiBsZXZlbCBvZiAmcXVvdDt3ZWxsJnF1b3Q7 IC0gYW5kIEkgd291bGQgcHJlZmVyIHRoYXQgZWNvc3lzdGVtIHRvIGJlIG9uZSB3aGVyZSBpdCdz IHBvc3NpYmxlIHRvIGZpZWxkIHRoZSBib3ggd2l0aG91dCBtYWtpbmcgcHJpb3IgYXJyYW5nZW1l bnRzIHdpdGggYW55b25lDQogYWJvdXQgbGljZW5zZXMuPGJyPg0KPGJyPg0KVGhpcyBhcmd1bWVu dCBoYXNuJ3QgY2hhbmdlZCBvbmUgd2hpdCBzaW5jZSBsYXN0IHRpbWUgd2UgZGlzY3Vzc2VkIGl0 LiBBbmQgSSBkb24ndCBzZWUgbXVjaCBtb3ZlbWVudCBvbiB0aGUgc3BlY2lmaWNzIG9mIHRoZSBw cm9wb3NhbHMgZWl0aGVyLjxicj4NCjxicj4NCldlJ2xsIGhhdmUgdG8gaW50ZXJvcGVyYXRlIHdl bGwgd2l0aCB0aGUgY29kZWNzIHdlIGZpZWxkLiBTbyB1c2luZyBzb21lIHRpbWUgdG8gZGlzY3Vz cyBkcmFmdC1pZXRmLXJ0Y3dlYi12aWRlbyBzZWVtcyB0byBtYWtlIHNlbnNlLiAoQW5kIDQuMSBp c24ndCBmaW5pc2hlZCBlaXRoZXIuIFRoZXJlJ3Mgb25lIHNlbnRlbmNlIHRoYXQgbmVlZHMgdG8g YmUgcmVtb3ZlZC4pPGJyPg0KPGJyPg0KSSB3b3VsZG4ndCBzYXkgSSdkIGJlIGhhcHB5IHRvIG5v dCBkaXNjdXNzIHRoaXMgaW4gSG9ub2x1bHUuIEJ1dCBJJ2QgcHJlZmVyIHRvIHJlLWRpc2N1c3Mg YmFzZWQgb24gdGhlIGtub3dsZWRnZSB0aGF0IHNvbWUgc2lnbmlmaWNhbnQgcGxheWVycyBoYXZl IGFjdHVhbGx5IGNoYW5nZWQgdGhlaXIgbWluZHMuPGJyPg0KPGJyPg0KQXQgdGhlIG1vbWVudCwg SSBkb24ndCBzZWUgc2lnbnMgdGhhdCBhbnkgb2YgdGhlIHBvbGwgcmVzcG9uZGVudHMgaGF2ZSBz YWlkICZxdW90O0kgaGF2ZSBjaGFuZ2VkIG15IG1pbmQmcXVvdDsuPHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPjxicj4NCjxicj4NCkhhcmFsZDwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBPY3QgMTYsIDIwMTQsIGF0IDI6 MjggUE0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25A Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNiBPY3Rv YmVyIDIwMTQgMTQ6MTcsIE1hdHRoZXcgS2F1Zm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hdHRo ZXdAbWF0dGhldy5hdCIgdGFyZ2V0PSJfYmxhbmsiPm1hdHRoZXdAbWF0dGhldy5hdDwvYT4mZ3Q7 IHdyb3RlOjxicj4NCkFuZCB0aGF0J3MgYmVjYXVzZSBzb21ldGhpbmcgc3Vic3RhbnRpdmUgaGFz IGNoYW5nZWQsIG9yIHNpbXBseSBiZWNhdXNlPGJyPg0Kd2FzdGluZyB0aGUgV0cgdGltZSBvbiB0 aGlzIGFnYWluIGlzIG1vcmUgZW50ZXJ0YWluaW5nIHRoYW4gYWN0dWFsbHk8YnI+DQpmaW5pc2hp bmcgYSBzcGVjaWZpY2F0aW9uIHRoYXQgY2FuIGJlIGluZGVwZW5kZW50bHkgaW1wbGVtZW50ZWQg YnkgYWxsPGJyPg0KYnJvd3NlciB2ZW5kb3JzPyAoQSBzcGVjaWZpY2F0aW9uIHRoYXQgd2UgYXJl IG5vd2hlcmUgbmVhciBoYXZpbmcsIGFzIGZhciBhczxicj4NCkkgY2FuIHRlbGwpPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJzb25hbGx5LCBJJ3ZlIGZvdW5kIHRoZSBy ZXByaWV2ZSBmcm9tIHRoaXMgZmlnaHQgcmVmcmVzaGluZy4mbmJzcDsgQW5kPGJyPg0KaXQgd291 bGQgYXBwZWFyIHRoYXQgd2UndmUgbWFkZSBzb21lIHJlYWwgcHJvZ3Jlc3MgYXMgYSByZXN1bHQu Jm5ic3A7IEknZDxicj4NCnN1Z2dlc3QgdGhhdCBpZiB3ZSBkb24ndCBoYXZlIG5ldyBpbmZvcm1h dGlvbiwgd2UgY29udGludWUgdG8gc3BlbmQ8YnI+DQpvdXIgdGltZSBwcm9kdWN0aXZlbHkuJm5i c3A7IElmIHdlIGNhbid0IGZpbmQgdG9waWNzIHRvIG9jY3VweSBvdXIgbWVldGluZzxicj4NCmFn ZW5kYSB0aW1lLCB0aGVuIG1heWJlIHdlIGNhbiBmcmVlIGFuIGFnZW5kYSBzbG90Ljxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K cnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRj d2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi ciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+QWxleC4gR291YWlsbGFyZCwgUGhELCBQaEQsIE1CQSA8bzpwPg0KPC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPkNUTyAtIFRlbWFzeXMgQ29tbXVuaWNhdGlvbnMsIFMncG9yZSAvIE1vdW50 YWluIFZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+UHJlc2lkZW50IC0gQ29TTW8g U29mdHdhcmUsIENhbWJyaWRnZSwgTUE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxh IGhyZWY9Imh0dHA6Ly9zZy5saW5rZWRpbi5jb20vYWdvdWFpbGxhcmQiIHRhcmdldD0iX2JsYW5r Ij5zZy5saW5rZWRpbi5jb20vYWdvdWFpbGxhcmQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjt0ZXh0LWluZGVudDotLjI1aW47bGluZS1oZWlnaHQ6MTQuNHB0O21zby1saXN0OmwwIGxldmVs MSBsZm80O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMzMz MzMzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTppbmhlcml0O2NvbG9yOiMz MzMzMzMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpy dGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvbmF0aGFu IFJvc2VuYmVyZywgUGguRC48YnI+DQo8YSBocmVmPSJtYWlsdG86amRyb3NlbkBqZHJvc2VuLm5l dCIgdGFyZ2V0PSJfYmxhbmsiPmpkcm9zZW5AamRyb3Nlbi5uZXQ8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cDovL3d3dy5qZHJvc2VuLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuamRyb3Nl bi5uZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRj d2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cnRjd2ViQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48 L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+LS0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5TdXJ2ZWlsbGFuY2UgaXMgcGVydmFzaXZlLiBHbyBE YXJrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E36D1A4AE0B6AA4091F1728D584A6AD24007E125fmsmsx118amrcor_-- From nobody Thu Oct 23 05:27:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C421AD0C7 for ; Thu, 23 Oct 2014 05:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbSmVRJR7qMw for ; Thu, 23 Oct 2014 05:27:13 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A7E071ACF13 for ; Thu, 23 Oct 2014 05:27:11 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id C53E893C1AF; Thu, 23 Oct 2014 12:27:08 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_E7B0BEFE-F6BC-48A3-B724-BB993AF9C57C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 23 Oct 2014 14:26:59 +0200 Message-Id: <27059BBA-4094-469F-BE8B-156C0692A02F@edvina.net> References: <7594FB04B1934943A5C02806D1A2204B1D4C18C0@ESESSMB209.ericsson.se> To: Benjamin Schwartz X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/S5AFGVpZG8kKy_z66zmD9JRf04k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 12:27:15 -0000 --Apple-Mail=_E7B0BEFE-F6BC-48A3-B724-BB993AF9C57C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Oct 2014, at 16:57, Benjamin Schwartz wrote: > FYI, the purpose of the RETURN draft = (https://tools.ietf.org/html/draft-schwartz-rtcweb-return-03) is to try = to specify the precise interaction and precedence when both the browser = and the application provide TURN servers. (It's not as simple as "one = or the other".) >=20 > I haven't considered the issues related to browser-provided STUN = servers, though. Cool! I'll take a look at that. Maybe Haralds draft need to refer to = that. /O >=20 > On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg = wrote: > Hi, >=20 > The advantage of an application configuration is that it can be = dynamically provided/updated, based on location based etc - assuming the = webpage provider has knowledge about STUN/TURN servers, of course. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. = Johansson > Sent: 22 October 2014 17:44 > To: rtcweb@ietf.org > Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt >=20 > Section 3.4 >=20 > " WebRTC browsers MUST support configuration of STUN and TURN servers, > both from browser configuration and from an application." >=20 >=20 > Should we mention which takes precedence? If configured in the = browser, start with that server. > If not use the one provided by the application. >=20 > Maybe we should clarify that turn DNS discovery MUST be used to = provide failover and load balancing. >=20 > /O > _______________________________________________ > 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 >=20 --Apple-Mail=_E7B0BEFE-F6BC-48A3-B724-BB993AF9C57C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 22 Oct 2014, at 16:57, Benjamin = Schwartz <bemasc@webrtc.org> = wrote:

FYI, the purpose of the RETURN draft (https= ://tools.ietf.org/html/draft-schwartz-rtcweb-return-03) is to try to = specify the precise interaction and precedence when both the browser and = the application provide TURN servers.  (It's not as simple as "one = or the other".)

I haven't considered the issues = related to browser-provided STUN servers, = though.
Cool! I'll take a look at that. Maybe = Haralds draft need to refer to = that.

/O

On Wed, Oct 22, = 2014 at 10:51 AM, Christer Holmberg <christer.holmberg@ericsson.com> = wrote:
Hi,

The advantage of an application configuration is that it can be = dynamically provided/updated, based on location based etc - assuming the = webpage provider has knowledge about STUN/TURN servers, of course.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Olle E. Johansson
Sent: 22 October 2014 17:44
To: rtcweb@ietf.org
Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt

Section 3.4

" WebRTC browsers MUST support configuration of STUN and TURN = servers,
   both from browser configuration and from an = application."


Should we mention which takes precedence? If configured in the browser, = start with that server.
If not use the one provided by the application.

Maybe we should clarify that turn DNS discovery MUST be used to provide = failover and load balancing.

/O
_______________________________________________
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


= --Apple-Mail=_E7B0BEFE-F6BC-48A3-B724-BB993AF9C57C-- From nobody Thu Oct 23 07:57:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C0A1A9241 for ; Thu, 23 Oct 2014 07:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrOkkZQHeYvv for ; Thu, 23 Oct 2014 07:57:38 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDA41A9238 for ; Thu, 23 Oct 2014 07:57:37 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id q5so943700wiv.2 for ; Thu, 23 Oct 2014 07:57: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; bh=/TwwLyEtF2fsbz+auQReYX72vdr0IofqbNGZHV0JYas=; b=DPaFDHIfASn70ZmOYQPVKLWQFYXmBjORbNoyYmhpxYe+fZAcOybCU3hHBo8J4/HYyV dz8YMCK89qKiHrIQi+0PxmAeftv+5AiEtcodvrFAlIIxYZzafokaAjp2qgiaGr6XPF1J w84GGe7Zy6ueg1KXFBjuD1A/RB1OKeB0SuC3/is065J35dk87zgTHS3JdlFaFY1S7+HI Oey1x7U8T0FBHDcl4qiS1l9++UHtYmAd58de3DN0K0o9X8gFemLrP9y/tidcA+6V52th F4IpyaLX/ySyy5kywCbNB9J/7RadYl2NDezYVRu5TRltmAodAg4/Wld9qgPas/YgrMU5 wQ/A== MIME-Version: 1.0 X-Received: by 10.194.92.12 with SMTP id ci12mr6088903wjb.6.1414076256332; Thu, 23 Oct 2014 07:57:36 -0700 (PDT) Received: by 10.194.95.194 with HTTP; Thu, 23 Oct 2014 07:57:35 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> Date: Thu, 23 Oct 2014 16:57:35 +0200 Message-ID: From: Leon Geyser To: "Cavigioli, Chris" Content-Type: multipart/alternative; boundary=047d7bfd08baf1b1590506184886 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DpKIWIUTcmCyPc_rzvuwE4V2H68 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 14:57:42 -0000 --047d7bfd08baf1b1590506184886 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In section '6 Use Cases' it seems like there isn't any transcoding required between AMR-WB <-> EVS Can an AMR-WB decoder decode an EVS stream? On 23 October 2014 12:15, Cavigioli, Chris wrote: > The GSMA white paper has been published. Download a copy here: > http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/ > > > > Note: Transcoding can be avoided by negotiating optional codecs and > finding a matching pair. The GSMA white paper doesn=E2=80=99t focus on t= hat case, > but instead specifically highlights the scenario where a pure WebRTC > endpoint is communicating with a pure 3GPP LTE VoLTE/ViLTE IMS endpoint, > assuming each endpoint ONLY has access to the MTI codecs in its respectiv= e > domain. In that case, the network is responsible to transcode between > (Opus or G.711, ) and (AMR or AMR-WB, H.264). > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Cavigioli, > Chris > *Sent:* Sunday, October 19, 2014 6:20 PM > *To:* Harald Alvestrand; Bernard Aboba > > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Harald said: > > =E2=80=9CWe made the mistake of having an MTI discussion previously with = not > enough details on that subject=E2=80=A6=E2=80=9D > > > > We didn=E2=80=99t have quantitative data earlier for a data-driven decisi= on. > Future Web =E2=80=93 LTE interop is important. A group of us in GSMA hav= e been > looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based > voice/video/messaging), specifically looking at user experience impact of > latency introduced by added in-network transcoding. GSMA has approved th= e > whitepaper and it is being prepared for public distribution. > > > > WebRTC =E2=80=93 LTE transcoding is now MANDATORY because of =E2=80=9CWeb= RTC Audio Codec > and Processing Requirements=E2=80=9D. > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio > codecs in WebRTC and in LTE are dissimilar. Thus, REGARDLESS of the vide= o > codecs, there is already a significant degradation imposed on Web =E2=80= =93 LTE > links if only MTI codecs are used. The only systems to avoid this are > those which implement OPTIONAL audio codecs to be transcoder-free with > LTE. The same can apply for video codecs. > > > > The GSMA whitepaper refers to: > > 1. Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by > 3GPP SA4 in August 2014. To paraphrase, performance objectives for maxim= um > VoLTE device delays in error and jitter free conditions and AMR speech > codec operation, the sum of the UE delays in sending and receiving > directions (TS + TR) should be =E2=89=A4 150ms. If this performance objec= tive > cannot be met, the sum of the UE delays in sending and receiving directio= ns > (TS + TR) shall in any case be =E2=89=A4 190ms. > > 2. OPUS =E2=80=93 AMR transcoding adds an additional 211.5 ms > implementation-agnostic (TS + TR) delay, including 40 ms for jitter > buffer and 40 ms for discontinuous reception (DRX). > > 3. To put these numbers in perspective, it is in general desirable to > minimize UE delays to ensure low enough end-to-end delays and hence a goo= d > conversational experience. Increasing delay causes people to double-talk > making conversations increasingly frustrating. Guidance to stay below 40= 0 > ms maximum one-way delay is found in ITU-T Recommendation G.114 and the > computational E-model is in ITU-T Recommendation G.107. > > > > This is a complex topic with many network factors in play. LTE operators > in 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS =E2=80=93 AM= R > transcoding in the network imposes an additional 211.5 ms on top of that, > just for audio. Optionally using AMR in WebRTC, those 211.5 ms can be > eliminated, delivering a superior end-user experience. > > > > CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a good > WebRTC =E2=80=93 LTE interop experience, emerging WebRTC systems must acc= ommodate > MTI codecs already deployed in the LTE domain and in mobile operating > systems, namely AMR/AMR-WB and H.264. > > > > POSITION: To be clear, several Intel SoCs launched at MWC this year for > smartphones and tablets support both VP8 and H.264 hardware encode and > decode =E2=80=93 so Intel is codec-neutral in this MTI debate. Additiona= lly, Intel > has high-performance solutions for transcoding. However, we wish to info= rm > the industry, with quantitative data, about impact to end-user experience > of mandating such transcoding so IETF can make a data-driven decision on > video codecs as well as reflect on the impact of already having mandated > transcoding on the audio side. > > > > Chris Cavigioli > > Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile > and Communications Group (MCG) > > +1 (415) 254-4545 mobile > > +1 (408) 653-8348 desk > > +1 (408) 884-2400 fax > > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review or distribution by others i= s > strictly prohibited. If you are not the intended recipient, please contac= t > the sender and delete all copies. > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *Bernard Aboba > *Sent:* Sunday, October 19, 2014 2:29 PM > *To:* Harald Alvestrand > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Harald said: > > > > "Bernard, > > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad....." > > > > [BA] I agree that the lack of interoperability is largely "codec > independent": that is, implementations based on different mechanisms fo= r > congestion control, repair, etc. will exhibit interoperability problems, > regardless of the codec chosen. The real test for RTCWEB will be to mov= e > beyond "interoperability of implementations sharing source code" to > "interoperability of independent implementations, based on open standards= ". > > > > > On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand > wrote: > > On 10/19/2014 05:43 PM, Bernard Aboba wrote: > > "And its one of the issues holding up wider adoption of the technology" > > > > [BA] Specifying an MTI encoder/decoder is not sufficient for > interoperability. It is also necessary to specify the transport in enoug= h > detail to allow independent implementations that interoperate well enough > to be usable in a wide variety of scenarios, including wireless networks > where loss is commonly experienced. > > > Bernard, > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad..... > > > > > > We made the mistake of having an MTI discussion previously with not enoug= h > details on that subject, particularly with respect to H.264. > draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > > > > So if we are to have the discussion again, it should occur in the context > of detailed specifications and interoperability reports. > > > > > > > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: > > I'm in favor of taking another run at this. > > > > The working group has repeatedly said that an MTI codec is something we > need to produce. And its one of the issues holding up wider adoption of t= he > technology (not the only one for sure). > > > > And things have changed since the last meeting, a year ago now (November > in Vancouver). Cisco's open264 plugin shipped and now just recently is > integrated into Firefox. iOS8 shipped with APIs for H264. There are other > things worth noting. Will this change the minds of everyone? Surely not. > Will it sway enough for us to achieve rough consensus? Maybe. IMHO - wort= h > finding out. > > > > On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < > agouaillard@gmail.com> wrote: > > +1 to not having MTI codec discussion unless some progress has been made > on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that ther= e > was no change on the members position. > > > > On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: > > On 10/17/2014 12:02 AM, Bernard Aboba wrote: > > One thing we could do instead of wasting time on MTI is to actually make > progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could > actually interoperate regardless of the codec. > > > The big argument for an MTI is actually the one stated in -overview: It > guards against interoperability failure. > > I would like to have an ecosystem where one can field a box, connect it t= o > everything else, and run well for *some* level of "well" - and I would > prefer that ecosystem to be one where it's possible to field the box > without making prior arrangements with anyone about licenses. > > This argument hasn't changed one whit since last time we discussed it. An= d > I don't see much movement on the specifics of the proposals either. > > We'll have to interoperate well with the codecs we field. So using some > time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn= 't > finished either. There's one sentence that needs to be removed.) > > I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd > prefer to re-discuss based on the knowledge that some significant players > have actually changed their minds. > > At the moment, I don't see signs that any of the poll respondents have > said "I have changed my mind". > > Harald > > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: > > On 16 October 2014 14:17, Matthew Kaufman wrote: > And that's because something substantive has changed, or simply because > wasting the WG time on this again is more entertaining than actually > finishing a specification that can be independently implemented by all > browser vendors? (A specification that we are nowhere near having, as far > as > I can tell) > > Personally, I've found the reprieve from this fight refreshing. And > it would appear that we've made some real progress as a result. I'd > suggest that if we don't have new information, we continue to spend > our time productively. If we can't find topics to occupy our meeting > agenda time, then maybe we can free an agenda slot. > > _______________________________________________ > 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 > > > > > > -- > > Alex. Gouaillard, PhD, PhD, MBA > > > -------------------------------------------------------------------------= ----------- > > CTO - Temasys Communications, S'pore / Mountain View > > President - CoSMo Software, Cambridge, MA > > > -------------------------------------------------------------------------= ----------- > > sg.linkedin.com/agouaillard > > =C2=B7 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > 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 > > > > -- > > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > 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 > > --047d7bfd08baf1b1590506184886 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In section '6 Use Cases' it seems like there = isn't any transcoding required between AMR-WB <-> EVS
Ca= n an AMR-WB decoder decode an EVS stream?

On 23 October 2014 12:15, Cavigioli, Chri= s <chris.cavigioli@intel.com> wrote:

The GSMA white paper has be= en published.=C2=A0 Download a copy here:=C2=A0 http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/

=C2=A0=

Note: Transcoding can be av= oided by negotiating optional codecs and finding a matching pair.=C2=A0 The= GSMA white paper doesn=E2=80=99t focus on that case, but instead specifica= lly highlights the scenario where a pure WebRTC endpoint is communicating with= a pure 3GPP LTE VoLTE/ViLTE IMS endpoint, assuming each endpoint ONLY has = access to the MTI codecs in its respective domain.=C2=A0 In that case, the = network is responsible to transcode between (Opus or G.711, <WebRTC MTI video codec TBD>) and (AMR or AMR-WB, H.= 264).=C2=A0

=C2=A0=

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Cavigioli, Chris
Sent: Sunday, October 19, 2014 6:20 PM
To: Harald Alvestrand; Bernard Aboba


Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?
<= /div>

=C2=A0

Harald said:=C2=A0

=E2=80=9CWe made the mistake of having an MTI discus= sion previously with not enough details on that subject=E2=80=A6=E2=80=9D

=C2=A0=

We didn=E2=80=99t have quan= titative data earlier for a data-driven decision.=C2=A0 Future Web =E2=80= =93 LTE interop is important.=C2=A0 A group of us in GSMA have been looking= at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messagin= g), specifically looking at user experience impact of latency introduced by= added in-network transcoding.=C2=A0 GSMA has approved the whitepaper and i= t is being prepared for public distribution.=C2=A0

=C2=A0=

WebRTC =E2=80=93 LTE transc= oding is now MANDATORY because of =E2=80=9CWebRTC Audio Codec and Processin= g Requirements=E2=80=9D. http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where M= TI audio codecs in WebRTC and in LTE are dissimilar.=C2=A0 Thus, REGARDLESS= of the video codecs, there is already a significant degradation imposed on Web =E2=80=93 LTE links if only MTI codecs are used.=C2=A0 The = only systems to avoid this are those which implement OPTIONAL audio codecs = to be transcoder-free with LTE.=C2=A0 The same can apply for video codecs.<= u>

=C2=A0=

The GSMA whitepaper refers = to:

1.=C2=A0=C2=A0=C2=A0=C2=A0 Quantitative voice-ove= r-LTE (VoLTE) delay limits were agreed-to by 3GPP SA4 in August 2014.=C2=A0= To paraphrase, performance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec ope= ration, the sum of the UE delays in sending and receiving directions (TS + TR) should be =E2=89=A4 150ms. If this performance ob= jective cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR)= shall in any case be =E2=89=A4 190ms.

2.=C2=A0=C2=A0=C2=A0=C2=A0 OPUS =E2=80=93 AMR tra= nscoding adds an additional 211.5 ms implementation-agnostic (TS= + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.=C2=A0=C2=A0=C2=A0=C2=A0 To put these numbers i= n perspective, it is in general desirable to minimize UE delays to ensure l= ow enough end-to-end delays and hence a good conversational experience.=C2=A0 Increasing delay causes people to double-talk making con= versations increasingly frustrating.=C2=A0 Guidance to stay below 400 ms ma= ximum one-way delay is found in ITU-T Recommendation G.114 and the computat= ional E-model is in ITU-T Recommendation G.107.

=C2=A0=

This is a complex topic wit= h many network factors in play.=C2=A0 LTE operators in 3GPP seek UE delays = (TS + TR) around 150 ms.=C2=A0 Adding OPUS =E2=80=93 AMR transcoding in the network imposes an additional 211.5 ms on top of th= at, just for audio.=C2=A0 Optionally using AMR in WebRTC, those 211.5 ms ca= n be eliminated, delivering a superior end-user experience.=C2=A0

=C2=A0=

CONCLUSION: =C2=A0regardles= s of MTI codec choices in WebRTC, to provide a good WebRTC =E2=80=93 LTE in= terop experience, emerging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely= AMR/AMR-WB and H.264.

=C2=A0=

POSITION:=C2=A0 To be clear= , several Intel SoCs launched at MWC this year for smartphones and tablets = support both VP8 and H.264 hardware encode and decode =E2=80=93 so Intel is codec-neutral in this MTI debate.=C2=A0 Additionally, Intel has high-pe= rformance solutions for transcoding.=C2=A0 However, we wish to inform the i= ndustry, with quantitative data, about impact to end-user experience of man= dating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impact of a= lready having mandated transcoding on the audio side.<= /p>

=C2=A0=

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group = (MCG)

+1 (415) 254-454= 5 mobile

+1 (408) 653-834= 8 desk

+1 (408) 884-240= 0 fax

This e-mail may contain confi= dential and privileged material for the sole use of the intended recipient(= s).=C2=A0 Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delet= e all copies.

=C2=A0=

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?=

=C2=A0

Harald said:=C2=A0

=C2=A0

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....&qu= ot;

=C2=A0

[BA] =C2=A0I agree that the lack of interoperability= is largely "codec independent": =C2=A0 that is, implementations = based on different mechanisms for congestion control, repair, etc. will exh= ibit interoperability problems, regardless of the codec chosen. =C2=A0 The real test for RTCWEB will be to move beyond "inter= operability of implementations sharing source code" =C2=A0to "int= eroperability of independent implementations, based on open standards"= . =C2=A0=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:<= u>

"And its one of the issues holding up wider ado= ption of the technology"

=C2=A0

[BA] Specifying an MTI encoder/decoder is not suffic= ient for interoperability.=C2=A0 It is also necessary to specify the transp= ort in enough detail to allow independent implementations that interoperate= well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienc= ed.=C2=A0


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....

=C2=A0<= /p>

=C2=A0

We made the mistake of having an MTI discussion prev= iously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.= =C2=A0

=C2=A0

So if we are to have the discussion again, it should= occur in the context of detailed specifications and interoperability repor= ts.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrose= n.net> wrote:

I'm in favor of taking another run at this. <= /u>

=C2=A0

The working group has repeatedly said that an MTI co= dec is something we need to produce. And its one of the issues holding up w= ider adoption of the technology (not the only one for sure).<= /p>

=C2=A0

And things have changed since the last meeting, a ye= ar ago now (November in Vancouver). Cisco's open264 plugin shipped and = now just recently is integrated into Firefox. iOS8 shipped with APIs for H2= 64. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough fo= r us to achieve rough consensus? Maybe. IMHO - worth finding out.=

=C2=A0

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLAR= D <agouaillar= d@gmail.com> wrote:

+1 to not having MTI codec discussion unless some pr= ogress has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing= harald's =C2=A0feeling that there was no change on the members positio= n.=C2=A0

=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:<= u>

One thing we could do instead of wasting time on MTI= is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-vi= deo, so we could actually interoperate regardless of the codec.


The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald

=C2=A0<= /p>

=C2=A0<= /p>

On Oct 16, 2014, at 2= :28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at>= ; wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)

Personally, I've found the reprieve from this fi= ght refreshing.=C2=A0 And
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



=C2=A0

--

Alex. Gouaillard, PhD,= PhD, MBA

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

CTO - Temasys Communic= ations, S'pore / Mountain View

President - CoSMo Soft= ware, Cambridge, MA

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

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0


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



=C2=A0

--


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

=C2=A0

=C2=A0<= /p> 

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

=C2=A0<= /p> 

-- 
Surveillance is pervasive. Go Dark.


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

=C2=A0


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


--047d7bfd08baf1b1590506184886-- From nobody Thu Oct 23 08:20:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCF51AC3EB for ; Thu, 23 Oct 2014 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjcOpIux-X3N for ; Thu, 23 Oct 2014 08:20:38 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970CA1AC3E4 for ; Thu, 23 Oct 2014 08:20:38 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so1398110wgh.9 for ; Thu, 23 Oct 2014 08:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BenCQbj+XvyTgz3z0MRneI8uXjTj/BnExazxsH/ClIc=; b=tZIvmLSxoAABZy8tb+8nAcVS28XBN2yhKVDgVL/qfxpeofhX9hXG/9hWfuiF5gUDRQ N1sUU22YAVBraWl+IdA51/6m2m6G4qttG+rCVtuAn1LkxnFLuZUCXWzhHShYPiiHrlBV ydMjq2gtvvByshVLRD0/3JVOJsu4YrAs5b6DKQQ8Eeek5az1qrLwhh6txz1RYw4pNXuY QulbNr+ehGxD3zx8n5H94kzGsm0fwARLtNvXFqiz4SZq/F/6HRyE6BVC7rHXtW50UjNj G9t73d8zF8omAXwH98L60tS5t+7uAFpGmAAF/1o9/yWuZDVFIkF7HQiNIDahWlwxWq6L Yw6Q== X-Received: by 10.180.100.106 with SMTP id ex10mr46438148wib.63.1414077637058; Thu, 23 Oct 2014 08:20:37 -0700 (PDT) Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id q10sm2484023wjq.35.2014.10.23.08.20.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 08:20:36 -0700 (PDT) Message-ID: <54491CCB.5090007@gmail.com> Date: Thu, 23 Oct 2014 17:20:43 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> In-Reply-To: <5448583B.5090109@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DjUmxDrtnOwG5Ty2-5bsGYkgN0E Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:20:40 -0000 On 23/10/2014 3:22, Timothy B. Terriberry wrote: > Sergio Garcia Murillo wrote: >> BTW, please, please, please, let's use the sssrc-group:FEC and send the >> FEC in its own ssrc stream, so we don't have to use RED anymore.. > > That may be fine for video, but the added header overhead for audio is > substantial (and there are a number of other problems that RED solves > there, as discussed at the last meeting). > Could you elaborate please? Best regards Sergio From nobody Thu Oct 23 08:51:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A721ACC8A for ; Thu, 23 Oct 2014 08:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azLhxGUJgYvW for ; Thu, 23 Oct 2014 08:51:12 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32ABD1AC40D for ; Thu, 23 Oct 2014 08:51:11 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id e89so882499qgf.8 for ; Thu, 23 Oct 2014 08:51:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=bkBphPyvJF2Odeir7mjXo4StiFQzuvZ6TEIIFhQKUzY=; b=LfgX1nbA9UB2t1LXtahBWOML7UfHYwBNgZqm1aVDbffzQxVAEPeabCIGMTbSJe2+vd 0hieBAntAl9BP9S977JlCAEiEOFLeTccflckrp7yswM38Hls6KBGOpJ32SHYDOEM0Bnz tjiZO4vOmNVHkojUj6kHnP2mB5vdP5F7iJBNq51jizQd3SL2XMSxaQYGYYzd3LyfDKrl nWriWixom8AL8NftOS/onyIgjvyRXWU3YmaVrZ2x58HL/lvxU9K/rlFu3+z83TqoFMVC /jMTS1KpbjSlQ4L2kYDxsFKTF+ec3MR1Y0FMYybaTm4SJIm+dCQy0wPuLEA20pIjhLGB VTUw== X-Gm-Message-State: ALoCoQnzif1gXk/CVAjZaPLoT0MSQopgwMycIdvPRSD4Dqe+QTQRL/3Rpm5TiHSS7Zqvj6tRUSSl X-Received: by 10.229.236.197 with SMTP id kl5mr8986074qcb.31.1414079471183; Thu, 23 Oct 2014 08:51:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Thu, 23 Oct 2014 08:50:50 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 23 Oct 2014 17:50:50 +0200 Message-ID: To: "Cavigioli, Chris" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/E9ewup0jW-qGVg1gOgW0zIY3cII Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:51:14 -0000 2014-10-23 12:15 GMT+02:00 Cavigioli, Chris : > The GSMA white paper has been published. Download a copy here: > http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/ Great. And now... can we go on with WebRTC and ignore anything 3GPP/GSMA sa= ys? --=20 I=C3=B1aki Baz Castillo From nobody Thu Oct 23 08:56:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F731ACD41 for ; Thu, 23 Oct 2014 08:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvuwFFS-jZgt for ; Thu, 23 Oct 2014 08:56:37 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E051ACD18 for ; Thu, 23 Oct 2014 08:56:20 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so3115226igb.2 for ; Thu, 23 Oct 2014 08:56: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=vhAOEEtfLo51YoaC+bN65o/8iTYvOQjPtOfLyMF1Jas=; b=nB4MHL36r+hFcS8k2BWs07clse69YH5qpZ6SlQoUxw81XvJMSzR7LWAKeT1Z400RLN Hlb5nGTH8yREP4dz4IsCLfJ/bZLxjPIsEguHnfjBG5OPtYv5dLIbx25x7xlDMiNL5gt+ 819xGULTPrb6zp9Ng+0rnZwvS0o8BzHV7iTa1aM2p3d9AqjiRh0GBwrnHbhIchct8hiG D5Y9QiPxB5ot8hm9J7kK2ln1lE3PE9zmZozTOh+5AjiQ14t7cQlvxRrkaSP1G/CCo/IY 9o4SGxjJkIiRmmpjJrKDaSZ1KbKLCxKHa4uBgpqRzDlxxRFpoYK4l2xaaVcuCHmpq5md lmRw== MIME-Version: 1.0 X-Received: by 10.43.90.198 with SMTP id bj6mr11297314icc.4.1414079779604; Thu, 23 Oct 2014 08:56:19 -0700 (PDT) Received: by 10.43.3.4 with HTTP; Thu, 23 Oct 2014 08:56:19 -0700 (PDT) In-Reply-To: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> Date: Thu, 23 Oct 2014 08:56:19 -0700 Message-ID: From: Ted Hardie To: "Cavigioli, Chris" Content-Type: multipart/alternative; boundary=bcaec5196bddf291130506191a6f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PYQ4jph76wZo2xGRrdDrAeUze7Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:56:42 -0000 --bcaec5196bddf291130506191a6f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 23, 2014 at 3:15 AM, Cavigioli, Chris wrote: > The GSMA white paper has been published. Download a copy here: > http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/ > =E2=80=8BNote that this document claims to be confidential. It's not clear= to me to whom, but IETF working groups are =E2=80=8Bnot limited in membership, so= sharing it with a working group is similar to making a public statement of its availability. Are you sure that this is the intent of the GSMA? > > Note: Transcoding can be avoided by negotiating optional codecs and > finding a matching pair. The GSMA white paper doesn=E2=80=99t focus on t= hat case, > but instead specifically highlights the scenario where a pure WebRTC > endpoint is communicating with a pure 3GPP LTE VoLTE/ViLTE IMS endpoint, > assuming each endpoint ONLY has access to the MTI codecs in its respectiv= e > domain. > =E2=80=8BWhile WebRTC has re-affirmed multiple times that a mandatory-to-im= plement codec is an important strategy for avoiding interoperability failure, the negotiation of mutually acceptable codecs is far more fundamental. You don't get a lot of list traffic on it because it is a given. For clients which expect to interoperate with telephony systems, the inclusion of other codecs that assist with that interoperation would be a far more natural strategy than relying on transcoding. There's been discussion of which those might be already, and we can have more. But please realize that there is a broad variety of client use cases here and that not all of them are in the realm of telephony. For those, the handheld device is not really an "IMS endpoint", it is a mobile platform--and the choice of what to include there is not limited to the mandatory to implement IMS codecs in any way of which I am aware. =E2=80=8Bregards, Ted Hardie /wearing no hat at the moment.=E2=80=8B > In that case, the network is responsible to transcode between (Opus or > G.711, ) and (AMR or AMR-WB, H.264). > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Cavigioli, > Chris > *Sent:* Sunday, October 19, 2014 6:20 PM > *To:* Harald Alvestrand; Bernard Aboba > > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Harald said: > > =E2=80=9CWe made the mistake of having an MTI discussion previously with = not > enough details on that subject=E2=80=A6=E2=80=9D > > > > We didn=E2=80=99t have quantitative data earlier for a data-driven decisi= on. > Future Web =E2=80=93 LTE interop is important. A group of us in GSMA hav= e been > looking at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based > voice/video/messaging), specifically looking at user experience impact of > latency introduced by added in-network transcoding. GSMA has approved th= e > whitepaper and it is being prepared for public distribution. > > > > WebRTC =E2=80=93 LTE transcoding is now MANDATORY because of =E2=80=9CWeb= RTC Audio Codec > and Processing Requirements=E2=80=9D. > http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where MTI audio > codecs in WebRTC and in LTE are dissimilar. Thus, REGARDLESS of the vide= o > codecs, there is already a significant degradation imposed on Web =E2=80= =93 LTE > links if only MTI codecs are used. The only systems to avoid this are > those which implement OPTIONAL audio codecs to be transcoder-free with > LTE. The same can apply for video codecs. > > > > The GSMA whitepaper refers to: > > 1. Quantitative voice-over-LTE (VoLTE) delay limits were agreed-to by > 3GPP SA4 in August 2014. To paraphrase, performance objectives for maxim= um > VoLTE device delays in error and jitter free conditions and AMR speech > codec operation, the sum of the UE delays in sending and receiving > directions (TS + TR) should be =E2=89=A4 150ms. If this performance objec= tive > cannot be met, the sum of the UE delays in sending and receiving directio= ns > (TS + TR) shall in any case be =E2=89=A4 190ms. > > 2. OPUS =E2=80=93 AMR transcoding adds an additional 211.5 ms > implementation-agnostic (TS + TR) delay, including 40 ms for jitter > buffer and 40 ms for discontinuous reception (DRX). > > 3. To put these numbers in perspective, it is in general desirable to > minimize UE delays to ensure low enough end-to-end delays and hence a goo= d > conversational experience. Increasing delay causes people to double-talk > making conversations increasingly frustrating. Guidance to stay below 40= 0 > ms maximum one-way delay is found in ITU-T Recommendation G.114 and the > computational E-model is in ITU-T Recommendation G.107. > > > > This is a complex topic with many network factors in play. LTE operators > in 3GPP seek UE delays (TS + TR) around 150 ms. Adding OPUS =E2=80=93 AM= R > transcoding in the network imposes an additional 211.5 ms on top of that, > just for audio. Optionally using AMR in WebRTC, those 211.5 ms can be > eliminated, delivering a superior end-user experience. > > > > CONCLUSION: regardless of MTI codec choices in WebRTC, to provide a good > WebRTC =E2=80=93 LTE interop experience, emerging WebRTC systems must acc= ommodate > MTI codecs already deployed in the LTE domain and in mobile operating > systems, namely AMR/AMR-WB and H.264. > > > > POSITION: To be clear, several Intel SoCs launched at MWC this year for > smartphones and tablets support both VP8 and H.264 hardware encode and > decode =E2=80=93 so Intel is codec-neutral in this MTI debate. Additiona= lly, Intel > has high-performance solutions for transcoding. However, we wish to info= rm > the industry, with quantitative data, about impact to end-user experience > of mandating such transcoding so IETF can make a data-driven decision on > video codecs as well as reflect on the impact of already having mandated > transcoding on the audio side. > > > > Chris Cavigioli > > Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile > and Communications Group (MCG) > > +1 (415) 254-4545 mobile > > +1 (408) 653-8348 desk > > +1 (408) 884-2400 fax > > This e-mail may contain confidential and privileged material for the sole > use of the intended recipient(s). Any review or distribution by others i= s > strictly prohibited. If you are not the intended recipient, please contac= t > the sender and delete all copies. > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *Bernard Aboba > *Sent:* Sunday, October 19, 2014 2:29 PM > *To:* Harald Alvestrand > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Plan for MTI video codec? > > > > Harald said: > > > > "Bernard, > > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad....." > > > > [BA] I agree that the lack of interoperability is largely "codec > independent": that is, implementations based on different mechanisms fo= r > congestion control, repair, etc. will exhibit interoperability problems, > regardless of the codec chosen. The real test for RTCWEB will be to mov= e > beyond "interoperability of implementations sharing source code" to > "interoperability of independent implementations, based on open standards= ". > > > > > On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand > wrote: > > On 10/19/2014 05:43 PM, Bernard Aboba wrote: > > "And its one of the issues holding up wider adoption of the technology" > > > > [BA] Specifying an MTI encoder/decoder is not sufficient for > interoperability. It is also necessary to specify the transport in enoug= h > detail to allow independent implementations that interoperate well enough > to be usable in a wide variety of scenarios, including wireless networks > where loss is commonly experienced. > > > Bernard, > > I think this is, to a large degree, codec independent. > > We have demonstrated interoperability on VP8 between Firefox and Chrome, > and usage of various mechanisms for congestion control and repair of pack= et > loss being applied in live services. > > So it can't be all bad..... > > > > > > We made the mistake of having an MTI discussion previously with not enoug= h > details on that subject, particularly with respect to H.264. > draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best. > > > > So if we are to have the discussion again, it should occur in the context > of detailed specifications and interoperability reports. > > > > > > > > > > > > On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg > wrote: > > I'm in favor of taking another run at this. > > > > The working group has repeatedly said that an MTI codec is something we > need to produce. And its one of the issues holding up wider adoption of t= he > technology (not the only one for sure). > > > > And things have changed since the last meeting, a year ago now (November > in Vancouver). Cisco's open264 plugin shipped and now just recently is > integrated into Firefox. iOS8 shipped with APIs for H264. There are other > things worth noting. Will this change the minds of everyone? Surely not. > Will it sway enough for us to achieve rough consensus? Maybe. IMHO - wort= h > finding out. > > > > On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLARD < > agouaillard@gmail.com> wrote: > > +1 to not having MTI codec discussion unless some progress has been made > on VP8 at MPEG. Any news on that? I'm sharing harald's feeling that ther= e > was no change on the members position. > > > > On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand > wrote: > > On 10/17/2014 12:02 AM, Bernard Aboba wrote: > > One thing we could do instead of wasting time on MTI is to actually make > progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-video, so we could > actually interoperate regardless of the codec. > > > The big argument for an MTI is actually the one stated in -overview: It > guards against interoperability failure. > > I would like to have an ecosystem where one can field a box, connect it t= o > everything else, and run well for *some* level of "well" - and I would > prefer that ecosystem to be one where it's possible to field the box > without making prior arrangements with anyone about licenses. > > This argument hasn't changed one whit since last time we discussed it. An= d > I don't see much movement on the specifics of the proposals either. > > We'll have to interoperate well with the codecs we field. So using some > time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn= 't > finished either. There's one sentence that needs to be removed.) > > I wouldn't say I'd be happy to not discuss this in Honolulu. But I'd > prefer to re-discuss based on the knowledge that some significant players > have actually changed their minds. > > At the moment, I don't see signs that any of the poll respondents have > said "I have changed my mind". > > Harald > > > > > > On Oct 16, 2014, at 2:28 PM, Martin Thomson > wrote: > > On 16 October 2014 14:17, Matthew Kaufman wrote: > And that's because something substantive has changed, or simply because > wasting the WG time on this again is more entertaining than actually > finishing a specification that can be independently implemented by all > browser vendors? (A specification that we are nowhere near having, as far > as > I can tell) > > Personally, I've found the reprieve from this fight refreshing. And > it would appear that we've made some real progress as a result. I'd > suggest that if we don't have new information, we continue to spend > our time productively. If we can't find topics to occupy our meeting > agenda time, then maybe we can free an agenda slot. > > _______________________________________________ > 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 > > > > > > -- > > Alex. Gouaillard, PhD, PhD, MBA > > > -------------------------------------------------------------------------= ----------- > > CTO - Temasys Communications, S'pore / Mountain View > > President - CoSMo Software, Cambridge, MA > > > -------------------------------------------------------------------------= ----------- > > sg.linkedin.com/agouaillard > > =C2=B7 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > 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 > > > > -- > > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > 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 > > --bcaec5196bddf291130506191a6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 23, 2014 at 3:15 AM= , Cavigioli, Chris <chris.cavigioli@intel.com> wrote= :

The GSMA white paper has be= en published.=C2=A0 Download a copy here:=C2=A0 http://www.gsma.com/newsroom/webrtc-codecs-draft-v1-3/


=E2=80=8B= Note that this document claims to be confidential.=C2=A0 It's not clear= to me to whom, but IETF working groups are =E2=80=8Bnot limited in members= hip, so sharing it with a working group is similar to making a public state= ment of its availability.=C2=A0 Are you sure that this is the intent of the= GSMA?

=C2=A0=

Note: Transcoding can be av= oided by negotiating optional codecs and finding a matching pair.=C2=A0 The= GSMA white paper doesn=E2=80=99t focus on that case, but instead specifica= lly highlights the scenario where a pure WebRTC endpoint is communicating with= a pure 3GPP LTE VoLTE/ViLTE IMS endpoint, assuming each endpoint ONLY has = access to the MTI codecs in its respective domain.=C2=A0

<= /div>

=E2=80=8BWhile WebRTC has re-affirmed = multiple times that a mandatory-to-implement codec is an important strategy= for avoiding interoperability failure, the negotiation of mutually accepta= ble codecs is far more fundamental.=C2=A0 You don't get a lot of list t= raffic on it because it is a given.=C2=A0

For clien= ts which expect to interoperate with telephony systems, the inclusion of ot= her codecs that assist with that interoperation would be a far more natural= strategy than relying on transcoding.=C2=A0 There's been discussion of= which those might be already, and we can have more.

But please real= ize that there is a broad variety of client use cases here and that not all= of them are in the realm of telephony.=C2=A0 For those, the handheld devic= e is not really an "IMS endpoint", it is a mobile platform--and t= he choice of what to include there is not limited to the mandatory to imple= ment IMS codecs in any way of which I am aware.

=E2= =80=8Bregards,

Ted Hardie
/wearing no hat at the moment.=E2=80=8B=



=C2=A0

In that case, the network is responsible to transcode betwee= n (Opus or G.711, <WebRTC MTI video codec TBD>) and (AMR or AMR-WB, H.= 264).=C2=A0

=C2=A0=

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Cavigioli, Chris
Sent: Sunday, October 19, 2014 6:20 PM
To: Harald Alvestrand; Bernard Aboba


Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?
<= /div>

=C2=A0

Harald said:=C2=A0

=E2=80=9CWe made the mistake of having an MTI discus= sion previously with not enough details on that subject=E2=80=A6=E2=80=9D

=C2=A0=

We didn=E2=80=99t have quan= titative data earlier for a data-driven decision.=C2=A0 Future Web =E2=80= =93 LTE interop is important.=C2=A0 A group of us in GSMA have been looking= at WebRTC interop with LTE (where 3GPP / GSMA defined IMS-based voice/video/messagin= g), specifically looking at user experience impact of latency introduced by= added in-network transcoding.=C2=A0 GSMA has approved the whitepaper and i= t is being prepared for public distribution.=C2=A0

=C2=A0=

WebRTC =E2=80=93 LTE transc= oding is now MANDATORY because of =E2=80=9CWebRTC Audio Codec and Processin= g Requirements=E2=80=9D. http://tools.ietf.org/html/draft-ietf-rtcweb-audio-05, where M= TI audio codecs in WebRTC and in LTE are dissimilar.=C2=A0 Thus, REGARDLESS= of the video codecs, there is already a significant degradation imposed on Web =E2=80=93 LTE links if only MTI codecs are used.=C2=A0 The = only systems to avoid this are those which implement OPTIONAL audio codecs = to be transcoder-free with LTE.=C2=A0 The same can apply for video codecs.<= u>

=C2=A0=

The GSMA whitepaper refers = to:

1.=C2=A0=C2=A0=C2=A0=C2=A0 Quantitative voice-ove= r-LTE (VoLTE) delay limits were agreed-to by 3GPP SA4 in August 2014.=C2=A0= To paraphrase, performance objectives for maximum VoLTE device delays in error and jitter free conditions and AMR speech codec ope= ration, the sum of the UE delays in sending and receiving directions (TS + TR) should be =E2=89=A4 150ms. If this performance ob= jective cannot be met, the sum of the UE delays in sending and receiving directions (TS + TR)= shall in any case be =E2=89=A4 190ms.

2.=C2=A0=C2=A0=C2=A0=C2=A0 OPUS =E2=80=93 AMR tra= nscoding adds an additional 211.5 ms implementation-agnostic (TS= + TR) delay, including 40 ms for jitter buffer and 40 ms for discontinuous reception (DRX).

3.=C2=A0=C2=A0=C2=A0=C2=A0 To put these numbers i= n perspective, it is in general desirable to minimize UE delays to ensure l= ow enough end-to-end delays and hence a good conversational experience.=C2=A0 Increasing delay causes people to double-talk making con= versations increasingly frustrating.=C2=A0 Guidance to stay below 400 ms ma= ximum one-way delay is found in ITU-T Recommendation G.114 and the computat= ional E-model is in ITU-T Recommendation G.107.

=C2=A0=

This is a complex topic wit= h many network factors in play.=C2=A0 LTE operators in 3GPP seek UE delays = (TS + TR) around 150 ms.=C2=A0 Adding OPUS =E2=80=93 AMR transcoding in the network imposes an additional 211.5 ms on top of th= at, just for audio.=C2=A0 Optionally using AMR in WebRTC, those 211.5 ms ca= n be eliminated, delivering a superior end-user experience.=C2=A0

=C2=A0=

CONCLUSION: =C2=A0regardles= s of MTI codec choices in WebRTC, to provide a good WebRTC =E2=80=93 LTE in= terop experience, emerging WebRTC systems must accommodate MTI codecs already deployed in the LTE domain and in mobile operating systems, namely= AMR/AMR-WB and H.264.

=C2=A0=

POSITION:=C2=A0 To be clear= , several Intel SoCs launched at MWC this year for smartphones and tablets = support both VP8 and H.264 hardware encode and decode =E2=80=93 so Intel is codec-neutral in this MTI debate.=C2=A0 Additionally, Intel has high-pe= rformance solutions for transcoding.=C2=A0 However, we wish to inform the i= ndustry, with quantitative data, about impact to end-user experience of man= dating such transcoding so IETF can make a data-driven decision on video codecs as well as reflect on the impact of a= lready having mandated transcoding on the audio side.<= /p>

=C2=A0=

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group = (MCG)

+1 (415) 254-454= 5 mobile

+1 (408) 653-834= 8 desk

+1 (408) 884-240= 0 fax

This e-mail may contain confi= dential and privileged material for the sole use of the intended recipient(= s).=C2=A0 Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delet= e all copies.

=C2=A0=

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 19, 2014 2:29 PM
To: Harald Alvestrand
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] Plan for MTI video codec?=

=C2=A0

Harald said:=C2=A0

=C2=A0

"Bernard,


I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....&qu= ot;

=C2=A0

[BA] =C2=A0I agree that the lack of interoperability= is largely "codec independent": =C2=A0 that is, implementations = based on different mechanisms for congestion control, repair, etc. will exh= ibit interoperability problems, regardless of the codec chosen. =C2=A0 The real test for RTCWEB will be to move beyond "inter= operability of implementations sharing source code" =C2=A0to "int= eroperability of independent implementations, based on open standards"= . =C2=A0=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 1:38 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/19/2014 05:43 PM, Bernard Aboba wrote:<= u>

"And its one of the issues holding up wider ado= ption of the technology"

=C2=A0

[BA] Specifying an MTI encoder/decoder is not suffic= ient for interoperability.=C2=A0 It is also necessary to specify the transp= ort in enough detail to allow independent implementations that interoperate= well enough to be usable in a wide variety of scenarios, including wireless networks where loss is commonly experienc= ed.=C2=A0


Bernard,

I think this is, to a large degree, codec independent.

We have demonstrated interoperability on VP8 between Firefox and Chrome, an= d usage of various mechanisms for congestion control and repair of packet l= oss being applied in live services.

So it can't be all bad.....

=C2=A0<= /p>

=C2=A0

We made the mistake of having an MTI discussion prev= iously with not enough details on that subject, particularly with respect t= o H.264. draft-ietf-rtcweb-video sections 4.2 - 4.4 remain sketchy at best.= =C2=A0

=C2=A0

So if we are to have the discussion again, it should= occur in the context of detailed specifications and interoperability repor= ts.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 19, 2014 at 8:14 AM, Jonathan Rosenberg = <jdrosen@jdrose= n.net> wrote:

I'm in favor of taking another run at this. <= /u>

=C2=A0

The working group has repeatedly said that an MTI co= dec is something we need to produce. And its one of the issues holding up w= ider adoption of the technology (not the only one for sure).<= /p>

=C2=A0

And things have changed since the last meeting, a ye= ar ago now (November in Vancouver). Cisco's open264 plugin shipped and = now just recently is integrated into Firefox. iOS8 shipped with APIs for H2= 64. There are other things worth noting. Will this change the minds of everyone? Surely not. Will it sway enough fo= r us to achieve rough consensus? Maybe. IMHO - worth finding out.=

=C2=A0

On Sat, Oct 18, 2014 at 5:08 PM, Alexandre GOUAILLAR= D <agouaillar= d@gmail.com> wrote:

+1 to not having MTI codec discussion unless some pr= ogress has been made on VP8 at MPEG.=C2=A0Any news on that? I'm sharing= harald's =C2=A0feeling that there was no change on the members positio= n.=C2=A0

=C2=A0

On Fri, Oct 17, 2014 at 9:22 PM, Harald Alvestrand &= lt;harald@alvestr= and.no> wrote:

On 10/17/2014 12:02 AM, Bernard Aboba wrote:<= u>

One thing we could do instead of wasting time on MTI= is to actually make progress on Sections 4.2 - 4.4 of draft-IETF-RTCWEB-vi= deo, so we could actually interoperate regardless of the codec.


The big argument for an MTI is actually the one stated in -overview: It gua= rds against interoperability failure.

I would like to have an ecosystem where one can field a box, connect it to = everything else, and run well for *some* level of "well" - and I = would prefer that ecosystem to be one where it's possible to field the = box without making prior arrangements with anyone about licenses.

This argument hasn't changed one whit since last time we discussed it. = And I don't see much movement on the specifics of the proposals either.=

We'll have to interoperate well with the codecs we field. So using some= time to discuss draft-ietf-rtcweb-video seems to make sense. (And 4.1 isn&= #39;t finished either. There's one sentence that needs to be removed.)<= br>
I wouldn't say I'd be happy to not discuss this in Honolulu. But I&= #39;d prefer to re-discuss based on the knowledge that some significant pla= yers have actually changed their minds.

At the moment, I don't see signs that any of the poll respondents have = said "I have changed my mind".

Harald

=C2=A0<= /p>

=C2=A0<= /p>

On Oct 16, 2014, at 2= :28 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 16 October 2014 14:17, Matthew Kaufman <matthew@matthew.at>= ; wrote:
And that's because something substantive has changed, or simply because=
wasting the WG time on this again is more entertaining than actually
finishing a specification that can be independently implemented by all
browser vendors? (A specification that we are nowhere near having, as far a= s
I can tell)

Personally, I've found the reprieve from this fi= ght refreshing.=C2=A0 And
it would appear that we've made some real progress as a result.=C2=A0 I= 'd
suggest that if we don't have new information, we continue to spend
our time productively.=C2=A0 If we can't find topics to occupy our meet= ing
agenda time, then maybe we can free an agenda slot.

_______________________________________________
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



=C2=A0

--

Alex. Gouaillard, PhD,= PhD, MBA

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

CTO - Temasys Communic= ations, S'pore / Mountain View

President - CoSMo Soft= ware, Cambridge, MA

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

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0


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



=C2=A0

--


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

=C2=A0

=C2=A0<= /p> 

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

=C2=A0<= /p> 

-- 
Surveillance is pervasive. Go Dark.


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

=C2=A0


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


--bcaec5196bddf291130506191a6f-- From nobody Thu Oct 23 09:47:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520051ACDAC for ; Thu, 23 Oct 2014 09:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GejXRqJW5Pm4 for ; Thu, 23 Oct 2014 09:47:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2141ACD9F for ; Thu, 23 Oct 2014 09:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14188; q=dns/txt; s=iport; t=1414082860; x=1415292460; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=hB76J1HQv43lBSz6vl8chaU438e6NKZp92O8rVDlgf4=; b=gih4HNv/mN0JExJS5zHs/46aw5oIFQQxA0zg2lGOrZc0qFAnDpWlT44H fdP2pjotyOQ21c9BaOOGeBEt5/R36ks9kTR1dwjOPYPKKZ074aZiN1wYc lqIUGtoSTFH2IQuLCLavH06n7oEviByJONDKm89Q78tEZOQKqv8IKo1/2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAJswSVStJA2I/2dsb2JhbABcgw5UXIMCyX6HSwIbdxYBfYQCAQEBAgIjEUAFEgEIDgkBAgIGIAIEHxEVCAkBBAENBQgSBYgOAxENtCOOFA2GOAEBAQEBAQEBAQEBAQEBAQEBARqBLIx3gV0nFhuCfjaBHgWFFYEYi1iERoUBg0I8gw2KVYJdhAGDeGwBBIEBQoEDAQEB X-IronPort-AV: E=Sophos;i="5.04,776,1406592000"; d="scan'208";a="365796363" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 23 Oct 2014 16:47:38 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9NGlcsI018486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 16:47:38 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.253]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 11:47:38 -0500 From: "David Benham (dbenham)" To: Stephan Wenger , Mohammed Raad Thread-Topic: [rtcweb] VCB/VP8 at ISO (was: Plan for MTI video codec? Thread-Index: Ac/u4QpTynKcTOrpTbORrU3FYdKQzg== Date: Thu, 23 Oct 2014 16:47:38 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC564EC6967@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.140.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g9cSvN0TS83hSUBW5KibZvZAfN8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] VCB/VP8 at ISO (was: Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 16:47:43 -0000 VGhlIHR5cGUgMyAobm8gUkFORCkgZnJvbSBOb2tpYSBpcyBub3Rld29ydGh5LCBidXQgbm90IGV4 YWN0bHkgbmV3cyB0byB1cyBoZXJlIGluIElFVEYgc2luY2UgdGhhdCBpcyBlc3NlbnRpYWxseSB3 aGF0IHRoZXkgaW5kaWNhdGVkIGluIHRoZWlyIElQUiBzdGF0ZW1lbnQgdG8gcmZjNjM4NiAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yMDM1LyAgKHdoZXJlIHRoZXkgaGFwcGVuIHRv IGxpc3QgcGF0ZW50cykuDQoNCldoYXQgaXMgcGVyaGFwcyBuZXdzeSwgaXMgdGhlIE1pY3Jvc29m dCB0eXBlIDIgKFJBTkQpIGRlY2xhcmF0aW9uIGZvciBWQ0IvVlA4IHdoaWNoIGNhbiBmb3VuZCBh dCAob3IgYXQgbGVhc3QgSSBjYW5ub3QgZmluZCBhIGxpa2Ugb25lIGluIGRhdGF0cmFja2VyKQ0K aHR0cDovL3BhdGVudHMuaWVjLmNoL1RJU1MvUGF0ZW50cy5uc2YvMC8xOEJENjAyRjVCQzlCRUU0 QzEyNTdENEUwMDMxODJDRS8kZmlsZS9JU09JRUMxNDQ5Ni0zMS5wZGYNCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU3Vi amVjdDogUmU6IFtydGN3ZWJdIFBsYW4gZm9yIE1USSB2aWRlbyBjb2RlYz8NCg0KSGkgU3RlcGhh biwNCg0KVGhlIHJlbGV2YW50IHNlY3Rpb24gaW4gdGhlIElTTy9JRUMgZGlyZWN0aXZlcyBpczoN Cg0KMi4xNC4zIFNob3VsZCBpdCBiZSByZXZlYWxlZCBhZnRlciBwdWJsaWNhdGlvbiBvZiBhIGRv Y3VtZW50IHRoYXQgbGljZW5jZXMgdW5kZXIgcGF0ZW50wqANCnJpZ2h0cywgd2hpY2ggYXBwZWFy IHRvIGNvdmVyIGl0ZW1zIGluY2x1ZGVkIGluIHRoZSBkb2N1bWVudCwgY2Fubm90IGJlIG9idGFp bmVkIHVuZGVywqANCnJlYXNvbmFibGUgYW5kIG5vbi1kaXNjcmltaW5hdG9yeSB0ZXJtcyBhbmQg Y29uZGl0aW9ucywgdGhlIGRvY3VtZW50IHNoYWxsIGJlIHJlZmVycmVkIGJhY2vCoA0KdG8gdGhl IHJlbGV2YW50IGNvbW1pdHRlZSBmb3IgZnVydGhlciBjb25zaWRlcmF0aW9uLg0KDQpJdCBzaG91 bGQgYmUgY2xlYXIgdG8gcGFydGljaXBhbnRzIGluIHRoaXMgZGlzY3Vzc2lvbiB0aGF0IG5vdCBs aXN0aW5nIGFueSBwYXRlbnRzIGluIGEgdHlwZSAzIGRlY2xhcmF0aW9uIG1ha2VzIGl0IGRpZmZp Y3VsdCB0byBjbGFpbSB0aGF0IGl0IGhhcyBiZWVuICJyZXZlYWxlZCBhZnRlciBwdWJsaWNhdGlv biBvZiBhIGRvY3VtZW50IHRoYXQgbGljZW5jZXMgdW5kZXIgcGF0ZW50wqANCnJpZ2h0cywgd2hp Y2ggYXBwZWFyIHRvIGNvdmVyIGl0ZW1zIGluY2x1ZGVkIGluIHRoZSBkb2N1bWVudCzCoMKgY2Fu bm90IGJlIG9idGFpbmVkIi4NCg0KU28sIHllcywgSVNPIGRvZXMgaGF2ZSBhIHdheSBvZiBkZWFs aW5nIHdpdGggc3VjaCBzaXR1YXRpb25zLiBNUEVHLCBzcGVjaWZpY2FsbHksIGhhcyBkZWFsdCB3 aXRoIHN1Y2ggYSBzaXR1YXRpb24gZHVyaW5nIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgQ0RWUyBz dGFuZGFyZCwgd2hpY2ggaXMgYSByZWNlbnQgc3RhbmRhcmQuIFRoZSBwYXRoIGNob3NlbiBpbiB0 aGF0IGluc3RhbmNlIHdhcyB0byB3b3JrIGFyb3VuZCB0aGUga25vd24gdW5saWNlbnNhYmxlIHBh dGVudC4NCg0KSWYgb25lIHdhcyB0byBhY2NlcHQgdGhlIGlkZWEgdGhhdCBhIHR5cGUtMyBkZWNs YXJhdGlvbiAoaS5lLiB0aGVyZSB3aWxsIGJlIG5vIGxpY2Vuc2luZykgd2l0aG91dCBiZWluZyB0 b2xkIGFzIHRvIHdoYXQgcGF0ZW50IHRoZSBjbGFpbSByZWZlcnMgdG8gc2hvdWxkIHN0b3AgdGhl IHByb2dyZXNzIG9mIGEgc3RhbmRhcmQsIHRoZW4gaXQgd291bGQgYmUgaW1wb3NzaWJsZSB0byBk ZXZlbG9wIGFueSBzdGFuZGFyZC4NCg0KUmVnYXJkcywNCk1vaGFtbWVkDQoNCk9uIFdlZCwgT2N0 IDIyLCAyMDE0IGF0IDk6NDUgUE0sIFN0ZXBoYW4gV2VuZ2VyIDxzdGV3ZUBzdGV3ZS5vcmc+IHdy b3RlOg0KSGksDQpJIGhhdmUgdG8gbWFrZSBvbmUgY29ycmVjdGlvbiBpbiB0aGUgbGlnaHQgb2Yg aW5mb3JtYXRpb24gdGhhdCBoYXMNCnN1cmZhY2VkIGF0IHRoZSBNUEVHIG1lZXRpbmcgY3VycmVu dGx5IG9uZ29pbmcgaW4gU3RyYXNib3VyZy7CoCAoSeKAmW0gbm90IGF0DQp0aGF0IG1lZXRpbmcg dGhpcyB0aW1lLCBidXQgYSBjb2xsZWFndWUgaXMgYW5kIHNoZSBicmllZmVkIG1lLikNCk5va2lh IGhhcyBtYWRlIE1QRUcgYW5kIElTTy9JRUMgb2ZmaWNpYWxseSBhd2FyZSB0aGF0IHRoZXkgYXJl IG5vdCB3aWxsaW5nDQp0byBsaWNlbnNlIGVzc2VudGlhbCBwYXRlbnRzIHVuZGVyIFJBTkQgdGVy bXMuwqAgRm9yIHRob3NlIHdpdGggTVBFRw0KZG9jdW1lbnQgYWNjZXNzLCBwbGVhc2Ugc2VlIE0z NDkxNy7CoCBUaGUgb2ZmaWNpYWwgZGVjbGFyYXRpb24gaXMgZGF0ZWQNCjkvMTkvMjAxNCwgYW5k IGlzIG5vdCB5ZXQgYXZhaWxhYmxlIGZyb20gdGhlIHJlc3BlY3RpdmUgZGF0YWJhc2VzLCBhcyBJ U08NCmlzIGFwcGFyZW50bHkgY2hhbmdpbmcgaXRzIHJlY29yZGF0aW9uIGluZnJhc3RydWN0dXJl Lg0KTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgam9pbnQgSVRVL0lTTy9JRUMgcGF0ZW50IHBvbGlj eSBpcyB0aGF0IG5vDQpzdGFuZGFyZCBjYW4gYmUgaXNzdWVkIHRoYXQgaGFzIGEgdHlwZSAzIGRl Y2xhcmF0aW9uIGFnYWluc3QgaXQuwqAgVG8gdGhlDQpiZXN0IG9mIG15IGtub3dsZWRnZSwgSVNP IGhhcyBubyBlc3RhYmxpc2hlZCBwcm9jZWR1cmUgaG93IHRvIGRlYWwgd2l0aA0KdHlwZSAzIChu b24tUkFORCkgZGVjbGFyYXRpb25zIGFuZCBzdGlsbCBrZWVwIHRoZSBzdGFuZGFyZCBwcm9qZWN0 IGdvaW5nLg0KVW5saWtlLCBmb3IgZXhhbXBsZSwgVzNDIGFuZCBpdHMgUGF0ZW50IEFkdmlzb3J5 IEdyb3Vwcy4NClRoZSBkZWNsYXJhdGlvbiBkb2VzIG5vdCBsaXN0IHNwZWNpZmljIHBhdGVudHMu IFRvIHRoZSBiZXN0IG9mIG15DQprbm93bGVkZ2UsIHN1Y2ggaW5mbyBpcyBub3QgcmVxdWlyZWQg KG9ubHkgZGVzaXJlZCkgZm9yIElTTyBhbmQgSUVDDQpzdGFuZGFyZGl6YXRpb24gd29yay0tb25l IG9mIHRoZSBmZXcgZGlmZmVyZW5jZXMgaW4gcGF0ZW50IHBvbGljeQ0KZ3VpZGVsaW5lcyBiZXR3 ZWVuIElUVSBhbmQgSVNPL0lFQy4NClRoZXJlZm9yZSwgSSBoYXZlIHRvIHJvdyBiYWNrIG9uIG15 IHByZXZpb3VzIHN0YXRlbWVudCBvZiBsaWtlbGluZXNzIG9mDQpoYXZpbmcgYW4gSVNPIG51bWJl ciBmb3IgVlA4IGFueXRpbWUgc29vbi7CoCBBdCB0aGlzIHBvaW50LCBJIGp1c3QgZG9u4oCZdA0K a25vdyB3aGV0aGVyLCBpZiBldmVyLCB0aGF0IHdpbGwgaGFwcGVuLg0KUmVnYXJkcywNClN0ZXBo YW4NCg0KDQpPbiAxMC8xOS8xNCwgNjoxMCBQTSwgIlN0ZXBoYW4gV2VuZ2VyIiA8c3Rld2VAc3Rl d2Uub3JnPiB3cm90ZToNCg0KPkhpLA0KPg0KPk9uIDEwLzE5LzE0LCA5OjE1IEFNLCAiV2F0c29u IExhZGQiIDx3YXRzb25ibGFkZEBnbWFpbC5jb20+IHdyb3RlOg0KPg0KPj5PbiBTdW4sIE9jdCAx OSwgMjAxNCBhdCA5OjEzIEFNLCBBbGV4YW5kcmUgR09VQUlMTEFSRA0KPj48YWdvdWFpbGxhcmRA Z21haWwuY29tPiB3cm90ZToNCj4+PiBAam9uYXRoYW4sDQo+Pj4NCj4+PiB3aGlsZSB5b3UgYXJl IHJpZ2h0IGFuZCBhdmFpbGFiaWxpdHkgb2YgMjY0IGltcGxlbWVudGF0aW9uIG9yIGhhcmR3YXJl DQo+Pj4gYWNjZWxlcmF0aW9uIGhhcyBpbXByb3ZlZCwgaXQgaGFzIG5ldmVyIGJlZW4gcmVwb3J0 ZWQgYXMgYSBwcm9ibGVtIGluDQo+Pj50aGUNCj4+PiBwcmV2aW91cyBwb29sIGJ5IGFueW9uZS4g VGhlIDI2NCByb3lhbHRpZXMsIGFuZCB0aGUgVlA4IElQIHJpc2tzIHdlcmUsDQo+Pj4gQUZBSVIs IHRoZSBtYWluIHJlYXNvbnMgdXNlZCBieSBpbmRpdmlkdWFscyB0byBqdXN0aWZ5IHRoZWlyIHBv c2l0aW9ucy4NCj4+PiBUb2RheSwgbm90aGluZyBoYXMgY2hhbmdlZCB3aXRoIHJlc3BlY3QgdG8g dGhvc2UgdHdvIGl0ZW1zIChldmVuIHRob3VnaA0KPj4+IHByb3ZpZGluZyBvcGVuMjY0IHJveWFs dGllcyBhbmQgYWJzb3JiaW5nIHRoZSBsaWNlbnNlIGNvc3QgZm9yIHNvbWUNCj4+PiBwbGF0Zm9y bXMgbWlnaHQgaGF2ZSBiZWVuIGEgc2V0IGluIHRoZSByaWdodCBkaXJlY3Rpb24pLiBUaGlzIGlz IHdoeSBJDQo+Pj50aGluaw0KPj4+IHRoZSBjb25kaXRpb25zIGFyZSBub3QgbWV0IGZvciBhIGNv bnNlbnN1cyB0byBiZSByZWFjaGVkLg0KPj4NCj4+QnV0IG5vdyBWUDggaXMgZ29pbmcgdGhyb3Vn aCBJU08sDQo+DQo+Li4uIGFuZCBpcyBpcyBESVMgYmFsbG90LsKgIEZldyBwcm9qZWN0cyBpbiBJ U08gZ2V0IHN0b3BwZWQgYXQgdGhhdCBzdGFnZS4NCj5UbyBtZSwgaXTCuXMgcHJldHR5IGNsZWFy IHRoYXQgVlA4IHdpbGwgaGF2ZSBhbiBJU08vSUVDIGJsZXNzaW5nIHdpdGhpbiBhDQo+eWVhciBv ciB0d28uwqAgV2l0aG91dCBzdWJzdGFudGlhbCB0ZWNobmljYWwgY2hhbmdlcy7CoCBHaXZlbiB0 aGUgdmVyeQ0KPmxpbWl0ZWQgcGFydGljaXBhdGlvbiBpbiB0aGUgcmVsZXZhbnQgc3ViZ3JvdXAg aW4gTVBFRywgaXTCuXMgdW5jbGVhciB0byBtZQ0KPndoYXQgZ29vZCB0aGF0IHdpbGwgZG8sIHRo b3VnaC4NCj4NCj4+YW5kIHRoZSBwZW9wbGUgY2xhaW1pbmcgcGF0ZW50cyBvbg0KPj5WUDggaGF2 ZSBoYWQgdGltZSB0byBzdWUsIGFuZCBoYXZlbid0Lg0KPg0KPlRoYXTCuXMgZmFjdHVhbGx5IGlu Y29ycmVjdC7CoCBUbyB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UsIHdoYXQgd291bGQgYmUNCj5m YWN0dWFsbHkgY29ycmVjdCBpcyB0aGlzOiBpbiB0d28gY2FzZXMsIGNvbXBhbmllcyBoYXZlIGJl ZW4gc3VlZCBvdmVyDQo+cGF0ZW50cyBhbGxlZ2VkbHkgcmVhZGluZyBvbiBWUDggaW4gdGhlIGNv bnRleHQgb2YgdGhlIHdpZGVyIMKzc21hcnRwaG9uZQ0KPndhcnPCsiBsYXdzdWl0cywgYW5kIHRo ZSBkZWZlbmRhbnRzIGhhdmUgd29uIG5vbi1pbmZyaW5nZW1lbnQgcnVsaW5ncyBpbg0KPnRoZSBm aXJzdCBpbnN0YW5jZSAodGhvdWdoLCBsYXN0IEkgbG9va2VkLCBhcHBlYWxzIHdlcmUgcGVuZGlu ZyBpbiBib3RoDQo+Y2FzZXMpLsKgIEF0IGxlYXN0IG9uZSBvdGhlciBjYXNlIHdhcyBzZXR0bGVk IG9uIHVuZGlzY2xvc2VkIHRlcm1zLsKgIFNvbWUNCj5vZiB0aGVzZSBjYXNlcyB3ZXJlIHdpZGVs eSByZXBvcnRlZCBpbiB0aGUgcHJlc3MsIG90aGVycyBhcmUgYSBsaXR0bGUgYml0DQo+aGFyZGVy IHRvIGZpbmQgd2l0aG91dCBhY2Nlc3MgdG8gbGVnYWwgc2VhcmNoIHRvb2xzLg0KPg0KPj5UaGF0 J3MgZXZpZGVuY2UgdGhhdCBzb21lDQo+PmNvbmNlcm5zIGFyZSBvdmVyYmxvd24uDQo+DQo+QW5k IHRoYXQgZGVwZW5kcyBvbiB5b3VyIHZpZXdwb2ludC4NCj4NCj5TdGVwaGFuDQo+DQo+Pj4gQWxl eC4NCj4+Pg0KPj4+IE9uIFN1biwgT2N0IDE5LCAyMDE0IGF0IDExOjQzIFBNLCBCZXJuYXJkIEFi b2JhDQo+Pj48YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+DQo+Pj4gd3JvdGU6DQo+Pj4+DQo+Pj4+ ICJBbmQgaXRzIG9uZSBvZiB0aGUgaXNzdWVzIGhvbGRpbmcgdXAgd2lkZXIgYWRvcHRpb24gb2Yg dGhlDQo+Pj4+dGVjaG5vbG9neSINCj4+Pj4NCj4+Pj4gW0JBXSBTcGVjaWZ5aW5nIGFuIE1USSBl bmNvZGVyL2RlY29kZXIgaXMgbm90IHN1ZmZpY2llbnQgZm9yDQo+Pj4+IGludGVyb3BlcmFiaWxp dHkuwqAgSXQgaXMgYWxzbyBuZWNlc3NhcnkgdG8gc3BlY2lmeSB0aGUgdHJhbnNwb3J0IGluDQo+ Pj4+ZW5vdWdoDQo+Pj4+IGRldGFpbCB0byBhbGxvdyBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlv bnMgdGhhdCBpbnRlcm9wZXJhdGUgd2VsbA0KPj4+PmVub3VnaCB0bw0KPj4+PiBiZSB1c2FibGUg aW4gYSB3aWRlIHZhcmlldHkgb2Ygc2NlbmFyaW9zLCBpbmNsdWRpbmcgd2lyZWxlc3MgbmV0d29y a3MNCj4+Pj53aGVyZQ0KPj4+PiBsb3NzIGlzIGNvbW1vbmx5IGV4cGVyaWVuY2VkLg0KPj4+Pg0K Pj4+PiBXZSBtYWRlIHRoZSBtaXN0YWtlIG9mIGhhdmluZyBhbiBNVEkgZGlzY3Vzc2lvbiBwcmV2 aW91c2x5IHdpdGggbm90DQo+Pj4+ZW5vdWdoDQo+Pj4+IGRldGFpbHMgb24gdGhhdCBzdWJqZWN0 LCBwYXJ0aWN1bGFybHkgd2l0aCByZXNwZWN0IHRvIEguMjY0Lg0KPj4+PiBkcmFmdC1pZXRmLXJ0 Y3dlYi12aWRlbyBzZWN0aW9ucyA0LjIgLSA0LjQgcmVtYWluIHNrZXRjaHkgYXQgYmVzdC4NCj4+ Pj4NCj4+Pj4gU28gaWYgd2UgYXJlIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24gYWdhaW4sIGl0IHNo b3VsZCBvY2N1ciBpbiB0aGUNCj4+Pj5jb250ZXh0DQo+Pj4+IG9mIGRldGFpbGVkIHNwZWNpZmlj YXRpb25zIGFuZCBpbnRlcm9wZXJhYmlsaXR5IHJlcG9ydHMuDQo+Pj4+DQo+Pj4+DQo+Pj4+IE9u IFN1biwgT2N0IDE5LCAyMDE0IGF0IDg6MTQgQU0sIEpvbmF0aGFuIFJvc2VuYmVyZw0KPj4+Pjxq ZHJvc2VuQGpkcm9zZW4ubmV0Pg0KPj4+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBJJ20gaW4gZmF2 b3Igb2YgdGFraW5nIGFub3RoZXIgcnVuIGF0IHRoaXMuDQo+Pj4+Pg0KPj4+Pj4gVGhlIHdvcmtp bmcgZ3JvdXAgaGFzIHJlcGVhdGVkbHkgc2FpZCB0aGF0IGFuIE1USSBjb2RlYyBpcyBzb21ldGhp bmcNCj4+Pj4+d2UNCj4+Pj4+IG5lZWQgdG8gcHJvZHVjZS4gQW5kIGl0cyBvbmUgb2YgdGhlIGlz c3VlcyBob2xkaW5nIHVwIHdpZGVyIGFkb3B0aW9uDQo+Pj4+Pm9mIHRoZQ0KPj4+Pj4gdGVjaG5v bG9neSAobm90IHRoZSBvbmx5IG9uZSBmb3Igc3VyZSkuDQo+Pj4+Pg0KPj4+Pj4gQW5kIHRoaW5n cyBoYXZlIGNoYW5nZWQgc2luY2UgdGhlIGxhc3QgbWVldGluZywgYSB5ZWFyIGFnbyBub3cNCj4+ Pj4+KE5vdmVtYmVyDQo+Pj4+PiBpbiBWYW5jb3V2ZXIpLiBDaXNjbydzIG9wZW4yNjQgcGx1Z2lu IHNoaXBwZWQgYW5kIG5vdyBqdXN0IHJlY2VudGx5DQo+Pj4+PmlzDQo+Pj4+PiBpbnRlZ3JhdGVk IGludG8gRmlyZWZveC4gaU9TOCBzaGlwcGVkIHdpdGggQVBJcyBmb3IgSDI2NC4gVGhlcmUgYXJl DQo+Pj4+Pm90aGVyDQo+Pj4+PiB0aGluZ3Mgd29ydGggbm90aW5nLiBXaWxsIHRoaXMgY2hhbmdl IHRoZSBtaW5kcyBvZiBldmVyeW9uZT8gU3VyZWx5DQo+Pj4+Pm5vdC4NCj4+Pj4+IFdpbGwgaXQg c3dheSBlbm91Z2ggZm9yIHVzIHRvIGFjaGlldmUgcm91Z2ggY29uc2Vuc3VzPyBNYXliZS4gSU1I TyAtDQo+Pj4+PndvcnRoDQo+Pj4+PiBmaW5kaW5nIG91dC4NCj4+Pj4+DQo+Pj4+PiBPbiBTYXQs IE9jdCAxOCwgMjAxNCBhdCA1OjA4IFBNLCBBbGV4YW5kcmUgR09VQUlMTEFSRA0KPj4+Pj4gPGFn b3VhaWxsYXJkQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiArMSB0byBub3QgaGF2 aW5nIE1USSBjb2RlYyBkaXNjdXNzaW9uIHVubGVzcyBzb21lIHByb2dyZXNzIGhhcyBiZWVuDQo+ Pj4+Pj5tYWRlDQo+Pj4+Pj4gb24gVlA4IGF0IE1QRUcuIEFueSBuZXdzIG9uIHRoYXQ/IEknbSBz aGFyaW5nIGhhcmFsZCdzwqAgZmVlbGluZyB0aGF0DQo+Pj4+Pj50aGVyZQ0KPj4+Pj4+IHdhcyBu byBjaGFuZ2Ugb24gdGhlIG1lbWJlcnMgcG9zaXRpb24uDQo+Pj4+Pj4NCj4+Pj4+PiBPbiBGcmks IE9jdCAxNywgMjAxNCBhdCA5OjIyIFBNLCBIYXJhbGQgQWx2ZXN0cmFuZA0KPj4+Pj4+IDxoYXJh bGRAYWx2ZXN0cmFuZC5ubz4gd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uIDEwLzE3LzIwMTQg MTI6MDIgQU0sIEJlcm5hcmQgQWJvYmEgd3JvdGU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT25lIHRo aW5nIHdlIGNvdWxkIGRvIGluc3RlYWQgb2Ygd2FzdGluZyB0aW1lIG9uIE1USSBpcyB0bw0KPj4+ Pj4+Pj5hY3R1YWxseQ0KPj4+Pj4+Pj4gbWFrZSBwcm9ncmVzcyBvbiBTZWN0aW9ucyA0LjIgLSA0 LjQgb2YgZHJhZnQtSUVURi1SVENXRUItdmlkZW8sIHNvDQo+Pj4+Pj4+PndlIGNvdWxkDQo+Pj4+ Pj4+PiBhY3R1YWxseSBpbnRlcm9wZXJhdGUgcmVnYXJkbGVzcyBvZiB0aGUgY29kZWMuDQo+Pj4+ Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZSBiaWcgYXJndW1lbnQgZm9yIGFuIE1USSBpcyBhY3R1 YWxseSB0aGUgb25lIHN0YXRlZCBpbg0KPj4+Pj4+Pi1vdmVydmlldzogSXQNCj4+Pj4+Pj4gZ3Vh cmRzIGFnYWluc3QgaW50ZXJvcGVyYWJpbGl0eSBmYWlsdXJlLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJ IHdvdWxkIGxpa2UgdG8gaGF2ZSBhbiBlY29zeXN0ZW0gd2hlcmUgb25lIGNhbiBmaWVsZCBhIGJv eCwNCj4+Pj4+Pj5jb25uZWN0IGl0DQo+Pj4+Pj4+IHRvIGV2ZXJ5dGhpbmcgZWxzZSwgYW5kIHJ1 biB3ZWxsIGZvciAqc29tZSogbGV2ZWwgb2YgIndlbGwiIC0gYW5kIEkNCj4+Pj4+Pj53b3VsZA0K Pj4+Pj4+PiBwcmVmZXIgdGhhdCBlY29zeXN0ZW0gdG8gYmUgb25lIHdoZXJlIGl0J3MgcG9zc2li bGUgdG8gZmllbGQgdGhlDQo+Pj4+Pj4+Ym94IHdpdGhvdXQNCj4+Pj4+Pj4gbWFraW5nIHByaW9y IGFycmFuZ2VtZW50cyB3aXRoIGFueW9uZSBhYm91dCBsaWNlbnNlcy4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gVGhpcyBhcmd1bWVudCBoYXNuJ3QgY2hhbmdlZCBvbmUgd2hpdCBzaW5jZSBsYXN0IHRpbWUg d2UgZGlzY3Vzc2VkDQo+Pj4+Pj4+aXQuDQo+Pj4+Pj4+IEFuZCBJIGRvbid0IHNlZSBtdWNoIG1v dmVtZW50IG9uIHRoZSBzcGVjaWZpY3Mgb2YgdGhlIHByb3Bvc2Fscw0KPj4+Pj4+PmVpdGhlci4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gV2UnbGwgaGF2ZSB0byBpbnRlcm9wZXJhdGUgd2VsbCB3aXRoIHRo ZSBjb2RlY3Mgd2UgZmllbGQuIFNvIHVzaW5nDQo+Pj4+Pj4+c29tZQ0KPj4+Pj4+PiB0aW1lIHRv IGRpc2N1c3MgZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8gc2VlbXMgdG8gbWFrZSBzZW5zZS4gKEFu ZA0KPj4+Pj4+PjQuMSBpc24ndA0KPj4+Pj4+PiBmaW5pc2hlZCBlaXRoZXIuIFRoZXJlJ3Mgb25l IHNlbnRlbmNlIHRoYXQgbmVlZHMgdG8gYmUgcmVtb3ZlZC4pDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkg d291bGRuJ3Qgc2F5IEknZCBiZSBoYXBweSB0byBub3QgZGlzY3VzcyB0aGlzIGluIEhvbm9sdWx1 LiBCdXQNCj4+Pj4+Pj5JJ2QNCj4+Pj4+Pj4gcHJlZmVyIHRvIHJlLWRpc2N1c3MgYmFzZWQgb24g dGhlIGtub3dsZWRnZSB0aGF0IHNvbWUgc2lnbmlmaWNhbnQNCj4+Pj4+Pj5wbGF5ZXJzDQo+Pj4+ Pj4+IGhhdmUgYWN0dWFsbHkgY2hhbmdlZCB0aGVpciBtaW5kcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g QXQgdGhlIG1vbWVudCwgSSBkb24ndCBzZWUgc2lnbnMgdGhhdCBhbnkgb2YgdGhlIHBvbGwgcmVz cG9uZGVudHMNCj4+Pj4+Pj5oYXZlDQo+Pj4+Pj4+IHNhaWQgIkkgaGF2ZSBjaGFuZ2VkIG15IG1p bmQiLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBIYXJhbGQNCj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gT24gT2N0IDE2LCAyMDE0LCBhdCAyOjI4IFBNLCBNYXJ0aW4gVGhvbXNvbg0KPj4+Pj4+Pj4+ IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ IE9uIDE2IE9jdG9iZXIgMjAxNCAxNDoxNywgTWF0dGhldyBLYXVmbWFuIDxtYXR0aGV3QG1hdHRo ZXcuYXQ+DQo+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+PiBBbmQgdGhhdCdzIGJlY2F1c2Ug c29tZXRoaW5nIHN1YnN0YW50aXZlIGhhcyBjaGFuZ2VkLCBvciBzaW1wbHkNCj4+Pj4+Pj4+Pj4g YmVjYXVzZQ0KPj4+Pj4+Pj4+PiB3YXN0aW5nIHRoZSBXRyB0aW1lIG9uIHRoaXMgYWdhaW4gaXMg bW9yZSBlbnRlcnRhaW5pbmcgdGhhbg0KPj4+Pj4+Pj4+PmFjdHVhbGx5DQo+Pj4+Pj4+Pj4+IGZp bmlzaGluZyBhIHNwZWNpZmljYXRpb24gdGhhdCBjYW4gYmUgaW5kZXBlbmRlbnRseSBpbXBsZW1l bnRlZA0KPj4+Pj4+Pj4+PmJ5DQo+Pj4+Pj4+Pj4+IGFsbA0KPj4+Pj4+Pj4+PiBicm93c2VyIHZl bmRvcnM/IChBIHNwZWNpZmljYXRpb24gdGhhdCB3ZSBhcmUgbm93aGVyZSBuZWFyDQo+Pj4+Pj4+ Pj4+aGF2aW5nLA0KPj4+Pj4+Pj4+PiBhcyBmYXIgYXMNCj4+Pj4+Pj4+Pj4gSSBjYW4gdGVsbCkN Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFBlcnNvbmFsbHksIEkndmUgZm91bmQgdGhlIHJlcHJpZXZl IGZyb20gdGhpcyBmaWdodCByZWZyZXNoaW5nLg0KPj4+Pj4+Pj4+QW5kDQo+Pj4+Pj4+Pj4gaXQg d291bGQgYXBwZWFyIHRoYXQgd2UndmUgbWFkZSBzb21lIHJlYWwgcHJvZ3Jlc3MgYXMgYSByZXN1 bHQuDQo+Pj4+Pj4+Pj5JJ2QNCj4+Pj4+Pj4+PiBzdWdnZXN0IHRoYXQgaWYgd2UgZG9uJ3QgaGF2 ZSBuZXcgaW5mb3JtYXRpb24sIHdlIGNvbnRpbnVlIHRvDQo+Pj4+Pj4+Pj5zcGVuZA0KPj4+Pj4+ Pj4+IG91ciB0aW1lIHByb2R1Y3RpdmVseS7CoCBJZiB3ZSBjYW4ndCBmaW5kIHRvcGljcyB0byBv Y2N1cHkgb3VyDQo+Pj4+Pj4+Pj5tZWV0aW5nDQo+Pj4+Pj4+Pj4gYWdlbmRhIHRpbWUsIHRoZW4g bWF5YmUgd2UgY2FuIGZyZWUgYW4gYWdlbmRhIHNsb3QuDQo+Pj4+Pj4+Pj4NCg0KDQo= From nobody Thu Oct 23 10:03:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C15B1A9155 for ; Thu, 23 Oct 2014 10:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRKjl4LS_NNY for ; Thu, 23 Oct 2014 10:03:35 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411EA1A90DE for ; Thu, 23 Oct 2014 10:03:34 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 7D4F049BF31BD; Thu, 23 Oct 2014 17:03:31 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9NH3WKo007198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 13:03:33 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 13:03:33 -0400 From: "Makaraju, Maridi Raju (Raju)" To: "Timothy B. Terriberry" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw85NsDgAD8OIA= Date: Thu, 23 Oct 2014 17:03:31 +0000 Message-ID: References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> In-Reply-To: <5448583B.5090109@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/m4rlHBy4b8PYVSD42oIfnJh8DTM Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 17:03:36 -0000 > Sergio Garcia Murillo wrote: > > BTW, please, please, please, let's use the sssrc-group:FEC and send the > > FEC in its own ssrc stream, so we don't have to use RED anymore.. >=20 > That may be fine for video, but the added header overhead for audio is > substantial (and there are a number of other problems that RED solves > there, as discussed at the last meeting). I am not sure if red+ulpfec is used for audio codecs in webrtc context (in = general it can be used for alternate encodings even for audio); OPUS does h= ave a built-in FEC so no need for red+ulpfec. For video, the RTP header overhead added by ssrc multiplexing is considerab= le (not significant, but can't be ignored) especially for the non-key frame= s and in mobile environments. Also, there is an additional problem with ssrc multiplexing for FEC. Use of red+ulpfec makes it easy for an SDP answerer to reject it by excludi= ng red+ulpfec payloads if it does not support FEC. But use of a=3Dssrc-grou= p:FEC makes it hard to reject the FEC part as the semantics are not support= ed by http://tools.ietf.org/html/rfc5576#section-8 This issue is being discussed at http://www.ietf.org/mail-archive/web/rtcwe= b/current/msg13249.html While Chrome supports red+ulpfec Firefox does not (yet!). If we use a=3Dssr= c-group:FEC then we will have an interop issue if Firefox rejects the entir= e video offer to strictly comply to RFC 5576 section 8. I wish the draft-ietf-rtcweb-rtp-usage (draft-ietf-rtcweb-audio or draft-ie= tf-rtcweb-video) says one way or other about how to convey FEC encoding (re= dundant encoding or ssrc multiplexing)=20 BR raju From nobody Thu Oct 23 10:10:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC84E1ACD9E for ; Thu, 23 Oct 2014 10:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeQKMoez8fml for ; Thu, 23 Oct 2014 10:10:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423A11ACE19 for ; Thu, 23 Oct 2014 10:10:43 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 23 Oct 2014 17:10:41 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.72]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.72]) with mapi id 15.00.1049.012; Thu, 23 Oct 2014 17:10:41 +0000 From: Stephan Wenger To: Stephan Wenger , Watson Ladd , Alexandre GOUAILLARD Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHOrixjgMwfvYrSbUqrcWE5foJ0c5wzqjdjgAAvKoCAAddnAIAAAwiAgAAJmQCAAQDrgIACFIiAgAEvmwCAAAgMAIAACFqAgAAAiICAACAFgIAEXFwAgAFnCIA= Date: Thu, 23 Oct 2014 17:10:41 +0000 Message-ID: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR07MB364; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(51704005)(479174003)(377454003)(120916001)(122556002)(99396003)(20776003)(64706001)(86362001)(92566001)(92726001)(101416001)(76176999)(50986999)(54356999)(16601075003)(15202345003)(31966008)(97736003)(4396001)(105586002)(77096002)(19580405001)(19580395003)(40100003)(93886004)(85306004)(36756003)(66066001)(76482002)(2656002)(80022003)(46102003)(21056001)(106116001)(106356001)(85852003)(95666004)(99286002)(87936001)(107046002)(15975445006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: text/plain; charset="euc-kr" Content-ID: <716B49CCFAB8C9488197A228F4A4D804@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EkSKP3G-458Wa8oKnM-J8vi9m04 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 17:10:56 -0000 QW5vdGhlciBjb3JyZWN0aW9uOiB0aGUgTVBFRyBkb2MgbnVtYmVyIGJlbG93IGlzIHdyb25nICh0 eXBvKS4gIFRoZQ0KY29ycmVjdCBudW1iZXIgaXMgTTM0OTcxLg0KU3RlcGhhbg0KDQpPbiAxMC8y Mi8xNCwgMTI6NDUgUE0sICJTdGVwaGFuIFdlbmdlciIgPHN0ZXdlQHN0ZXdlLm9yZz4gd3JvdGU6 DQoNCj5IaSwNCj5JIGhhdmUgdG8gbWFrZSBvbmUgY29ycmVjdGlvbiBpbiB0aGUgbGlnaHQgb2Yg aW5mb3JtYXRpb24gdGhhdCBoYXMNCj5zdXJmYWNlZCBhdCB0aGUgTVBFRyBtZWV0aW5nIGN1cnJl bnRseSBvbmdvaW5nIGluIFN0cmFzYm91cmcuICAoSaGvbSBub3QgYXQNCj50aGF0IG1lZXRpbmcg dGhpcyB0aW1lLCBidXQgYSBjb2xsZWFndWUgaXMgYW5kIHNoZSBicmllZmVkIG1lLikNCj5Ob2tp YSBoYXMgbWFkZSBNUEVHIGFuZCBJU08vSUVDIG9mZmljaWFsbHkgYXdhcmUgdGhhdCB0aGV5IGFy ZSBub3Qgd2lsbGluZw0KPnRvIGxpY2Vuc2UgZXNzZW50aWFsIHBhdGVudHMgdW5kZXIgUkFORCB0 ZXJtcy4gIEZvciB0aG9zZSB3aXRoIE1QRUcNCj5kb2N1bWVudCBhY2Nlc3MsIHBsZWFzZSBzZWUg TTM0OTE3LiAgVGhlIG9mZmljaWFsIGRlY2xhcmF0aW9uIGlzIGRhdGVkDQo+OS8xOS8yMDE0LCBh bmQgaXMgbm90IHlldCBhdmFpbGFibGUgZnJvbSB0aGUgcmVzcGVjdGl2ZSBkYXRhYmFzZXMsIGFz IElTTw0KPmlzIGFwcGFyZW50bHkgY2hhbmdpbmcgaXRzIHJlY29yZGF0aW9uIGluZnJhc3RydWN0 dXJlLg0KPk15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGpvaW50IElUVS9JU08vSUVDIHBhdGVudCBw b2xpY3kgaXMgdGhhdCBubw0KPnN0YW5kYXJkIGNhbiBiZSBpc3N1ZWQgdGhhdCBoYXMgYSB0eXBl IDMgZGVjbGFyYXRpb24gYWdhaW5zdCBpdC4gIFRvIHRoZQ0KPmJlc3Qgb2YgbXkga25vd2xlZGdl LCBJU08gaGFzIG5vIGVzdGFibGlzaGVkIHByb2NlZHVyZSBob3cgdG8gZGVhbCB3aXRoDQo+dHlw ZSAzIChub24tUkFORCkgZGVjbGFyYXRpb25zIGFuZCBzdGlsbCBrZWVwIHRoZSBzdGFuZGFyZCBw cm9qZWN0IGdvaW5nLg0KPlVubGlrZSwgZm9yIGV4YW1wbGUsIFczQyBhbmQgaXRzIFBhdGVudCBB ZHZpc29yeSBHcm91cHMuDQo+VGhlIGRlY2xhcmF0aW9uIGRvZXMgbm90IGxpc3Qgc3BlY2lmaWMg cGF0ZW50cy4gVG8gdGhlIGJlc3Qgb2YgbXkNCj5rbm93bGVkZ2UsIHN1Y2ggaW5mbyBpcyBub3Qg cmVxdWlyZWQgKG9ubHkgZGVzaXJlZCkgZm9yIElTTyBhbmQgSUVDDQo+c3RhbmRhcmRpemF0aW9u IHdvcmstLW9uZSBvZiB0aGUgZmV3IGRpZmZlcmVuY2VzIGluIHBhdGVudCBwb2xpY3kNCj5ndWlk ZWxpbmVzIGJldHdlZW4gSVRVIGFuZCBJU08vSUVDLg0KPlRoZXJlZm9yZSwgSSBoYXZlIHRvIHJv dyBiYWNrIG9uIG15IHByZXZpb3VzIHN0YXRlbWVudCBvZiBsaWtlbGluZXNzIG9mDQo+aGF2aW5n IGFuIElTTyBudW1iZXIgZm9yIFZQOCBhbnl0aW1lIHNvb24uICBBdCB0aGlzIHBvaW50LCBJIGp1 c3QgZG9uoa90DQo+a25vdyB3aGV0aGVyLCBpZiBldmVyLCB0aGF0IHdpbGwgaGFwcGVuLg0KPlJl Z2FyZHMsDQo+U3RlcGhhbg0KPg0KPg0KPk9uIDEwLzE5LzE0LCA2OjEwIFBNLCAiU3RlcGhhbiBX ZW5nZXIiIDxzdGV3ZUBzdGV3ZS5vcmc+IHdyb3RlOg0KPg0KPj5IaSwNCj4+DQo+Pk9uIDEwLzE5 LzE0LCA5OjE1IEFNLCAiV2F0c29uIExhZGQiIDx3YXRzb25ibGFkZEBnbWFpbC5jb20+IHdyb3Rl Og0KPj4NCj4+Pk9uIFN1biwgT2N0IDE5LCAyMDE0IGF0IDk6MTMgQU0sIEFsZXhhbmRyZSBHT1VB SUxMQVJEDQo+Pj48YWdvdWFpbGxhcmRAZ21haWwuY29tPiB3cm90ZToNCj4+Pj4gQGpvbmF0aGFu LA0KPj4+Pg0KPj4+PiB3aGlsZSB5b3UgYXJlIHJpZ2h0IGFuZCBhdmFpbGFiaWxpdHkgb2YgMjY0 IGltcGxlbWVudGF0aW9uIG9yIGhhcmR3YXJlDQo+Pj4+IGFjY2VsZXJhdGlvbiBoYXMgaW1wcm92 ZWQsIGl0IGhhcyBuZXZlciBiZWVuIHJlcG9ydGVkIGFzIGEgcHJvYmxlbSBpbg0KPj4+PnRoZQ0K Pj4+PiBwcmV2aW91cyBwb29sIGJ5IGFueW9uZS4gVGhlIDI2NCByb3lhbHRpZXMsIGFuZCB0aGUg VlA4IElQIHJpc2tzIHdlcmUsDQo+Pj4+IEFGQUlSLCB0aGUgbWFpbiByZWFzb25zIHVzZWQgYnkg aW5kaXZpZHVhbHMgdG8ganVzdGlmeSB0aGVpcg0KPj4+PnBvc2l0aW9ucy4NCj4+Pj4gVG9kYXks IG5vdGhpbmcgaGFzIGNoYW5nZWQgd2l0aCByZXNwZWN0IHRvIHRob3NlIHR3byBpdGVtcyAoZXZl bg0KPj4+PnRob3VnaA0KPj4+PiBwcm92aWRpbmcgb3BlbjI2NCByb3lhbHRpZXMgYW5kIGFic29y YmluZyB0aGUgbGljZW5zZSBjb3N0IGZvciBzb21lDQo+Pj4+IHBsYXRmb3JtcyBtaWdodCBoYXZl IGJlZW4gYSBzZXQgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbikuIFRoaXMgaXMgd2h5IEkNCj4+Pj50 aGluaw0KPj4+PiB0aGUgY29uZGl0aW9ucyBhcmUgbm90IG1ldCBmb3IgYSBjb25zZW5zdXMgdG8g YmUgcmVhY2hlZC4NCj4+Pg0KPj4+QnV0IG5vdyBWUDggaXMgZ29pbmcgdGhyb3VnaCBJU08sDQo+ Pg0KPj4uLi4gYW5kIGlzIGlzIERJUyBiYWxsb3QuICBGZXcgcHJvamVjdHMgaW4gSVNPIGdldCBz dG9wcGVkIGF0IHRoYXQgc3RhZ2UuDQo+PlRvIG1lLCBpdKn2cyBwcmV0dHkgY2xlYXIgdGhhdCBW UDggd2lsbCBoYXZlIGFuIElTTy9JRUMgYmxlc3Npbmcgd2l0aGluIGENCj4+eWVhciBvciB0d28u ICBXaXRob3V0IHN1YnN0YW50aWFsIHRlY2huaWNhbCBjaGFuZ2VzLiAgR2l2ZW4gdGhlIHZlcnkN Cj4+bGltaXRlZCBwYXJ0aWNpcGF0aW9uIGluIHRoZSByZWxldmFudCBzdWJncm91cCBpbiBNUEVH LCBpdKn2cyB1bmNsZWFyIHRvDQo+Pm1lDQo+PndoYXQgZ29vZCB0aGF0IHdpbGwgZG8sIHRob3Vn aC4NCj4+DQo+Pj5hbmQgdGhlIHBlb3BsZSBjbGFpbWluZyBwYXRlbnRzIG9uDQo+Pj5WUDggaGF2 ZSBoYWQgdGltZSB0byBzdWUsIGFuZCBoYXZlbid0Lg0KPj4NCj4+VGhhdKn2cyBmYWN0dWFsbHkg aW5jb3JyZWN0LiAgVG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLCB3aGF0IHdvdWxkIGJlDQo+ PmZhY3R1YWxseSBjb3JyZWN0IGlzIHRoaXM6IGluIHR3byBjYXNlcywgY29tcGFuaWVzIGhhdmUg YmVlbiBzdWVkIG92ZXINCj4+cGF0ZW50cyBhbGxlZ2VkbHkgcmVhZGluZyBvbiBWUDggaW4gdGhl IGNvbnRleHQgb2YgdGhlIHdpZGVyIKn4c21hcnRwaG9uZQ0KPj53YXJzqfcgbGF3c3VpdHMsIGFu ZCB0aGUgZGVmZW5kYW50cyBoYXZlIHdvbiBub24taW5mcmluZ2VtZW50IHJ1bGluZ3MgaW4NCj4+ dGhlIGZpcnN0IGluc3RhbmNlICh0aG91Z2gsIGxhc3QgSSBsb29rZWQsIGFwcGVhbHMgd2VyZSBw ZW5kaW5nIGluIGJvdGgNCj4+Y2FzZXMpLiAgQXQgbGVhc3Qgb25lIG90aGVyIGNhc2Ugd2FzIHNl dHRsZWQgb24gdW5kaXNjbG9zZWQgdGVybXMuICBTb21lDQo+Pm9mIHRoZXNlIGNhc2VzIHdlcmUg d2lkZWx5IHJlcG9ydGVkIGluIHRoZSBwcmVzcywgb3RoZXJzIGFyZSBhIGxpdHRsZSBiaXQNCj4+ aGFyZGVyIHRvIGZpbmQgd2l0aG91dCBhY2Nlc3MgdG8gbGVnYWwgc2VhcmNoIHRvb2xzLg0KPj4N Cj4+PlRoYXQncyBldmlkZW5jZSB0aGF0IHNvbWUNCj4+PmNvbmNlcm5zIGFyZSBvdmVyYmxvd24u DQo+Pg0KPj5BbmQgdGhhdCBkZXBlbmRzIG9uIHlvdXIgdmlld3BvaW50Lg0KPj4NCj4+U3RlcGhh bg0KPj4NCj4+Pg0KPj4+Pg0KPj4+PiBBbGV4Lg0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiBTdW4sIE9j dCAxOSwgMjAxNCBhdCAxMTo0MyBQTSwgQmVybmFyZCBBYm9iYQ0KPj4+PjxiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbT4NCj4+Pj4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gIkFuZCBpdHMgb25lIG9mIHRo ZSBpc3N1ZXMgaG9sZGluZyB1cCB3aWRlciBhZG9wdGlvbiBvZiB0aGUNCj4+Pj4+dGVjaG5vbG9n eSINCj4+Pj4+DQo+Pj4+PiBbQkFdIFNwZWNpZnlpbmcgYW4gTVRJIGVuY29kZXIvZGVjb2RlciBp cyBub3Qgc3VmZmljaWVudCBmb3INCj4+Pj4+IGludGVyb3BlcmFiaWxpdHkuICBJdCBpcyBhbHNv IG5lY2Vzc2FyeSB0byBzcGVjaWZ5IHRoZSB0cmFuc3BvcnQgaW4NCj4+Pj4+ZW5vdWdoDQo+Pj4+ PiBkZXRhaWwgdG8gYWxsb3cgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIHRoYXQgaW50ZXJv cGVyYXRlIHdlbGwNCj4+Pj4+ZW5vdWdoIHRvDQo+Pj4+PiBiZSB1c2FibGUgaW4gYSB3aWRlIHZh cmlldHkgb2Ygc2NlbmFyaW9zLCBpbmNsdWRpbmcgd2lyZWxlc3MgbmV0d29ya3MNCj4+Pj4+d2hl cmUNCj4+Pj4+IGxvc3MgaXMgY29tbW9ubHkgZXhwZXJpZW5jZWQuDQo+Pj4+Pg0KPj4+Pj4gV2Ug bWFkZSB0aGUgbWlzdGFrZSBvZiBoYXZpbmcgYW4gTVRJIGRpc2N1c3Npb24gcHJldmlvdXNseSB3 aXRoIG5vdA0KPj4+Pj5lbm91Z2gNCj4+Pj4+IGRldGFpbHMgb24gdGhhdCBzdWJqZWN0LCBwYXJ0 aWN1bGFybHkgd2l0aCByZXNwZWN0IHRvIEguMjY0Lg0KPj4+Pj4gZHJhZnQtaWV0Zi1ydGN3ZWIt dmlkZW8gc2VjdGlvbnMgNC4yIC0gNC40IHJlbWFpbiBza2V0Y2h5IGF0IGJlc3QuDQo+Pj4+Pg0K Pj4+Pj4gU28gaWYgd2UgYXJlIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24gYWdhaW4sIGl0IHNob3Vs ZCBvY2N1ciBpbiB0aGUNCj4+Pj4+Y29udGV4dA0KPj4+Pj4gb2YgZGV0YWlsZWQgc3BlY2lmaWNh dGlvbnMgYW5kIGludGVyb3BlcmFiaWxpdHkgcmVwb3J0cy4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gU3VuLCBPY3QgMTksIDIwMTQgYXQgODoxNCBBTSwgSm9u YXRoYW4gUm9zZW5iZXJnDQo+Pj4+PjxqZHJvc2VuQGpkcm9zZW4ubmV0Pg0KPj4+Pj4gd3JvdGU6 DQo+Pj4+Pj4NCj4+Pj4+PiBJJ20gaW4gZmF2b3Igb2YgdGFraW5nIGFub3RoZXIgcnVuIGF0IHRo aXMuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgd29ya2luZyBncm91cCBoYXMgcmVwZWF0ZWRseSBzYWlk IHRoYXQgYW4gTVRJIGNvZGVjIGlzIHNvbWV0aGluZw0KPj4+Pj4+d2UNCj4+Pj4+PiBuZWVkIHRv IHByb2R1Y2UuIEFuZCBpdHMgb25lIG9mIHRoZSBpc3N1ZXMgaG9sZGluZyB1cCB3aWRlciBhZG9w dGlvbg0KPj4+Pj4+b2YgdGhlDQo+Pj4+Pj4gdGVjaG5vbG9neSAobm90IHRoZSBvbmx5IG9uZSBm b3Igc3VyZSkuDQo+Pj4+Pj4NCj4+Pj4+PiBBbmQgdGhpbmdzIGhhdmUgY2hhbmdlZCBzaW5jZSB0 aGUgbGFzdCBtZWV0aW5nLCBhIHllYXIgYWdvIG5vdw0KPj4+Pj4+KE5vdmVtYmVyDQo+Pj4+Pj4g aW4gVmFuY291dmVyKS4gQ2lzY28ncyBvcGVuMjY0IHBsdWdpbiBzaGlwcGVkIGFuZCBub3cganVz dCByZWNlbnRseQ0KPj4+Pj4+aXMNCj4+Pj4+PiBpbnRlZ3JhdGVkIGludG8gRmlyZWZveC4gaU9T OCBzaGlwcGVkIHdpdGggQVBJcyBmb3IgSDI2NC4gVGhlcmUgYXJlDQo+Pj4+Pj5vdGhlcg0KPj4+ Pj4+IHRoaW5ncyB3b3J0aCBub3RpbmcuIFdpbGwgdGhpcyBjaGFuZ2UgdGhlIG1pbmRzIG9mIGV2 ZXJ5b25lPyBTdXJlbHkNCj4+Pj4+Pm5vdC4NCj4+Pj4+PiBXaWxsIGl0IHN3YXkgZW5vdWdoIGZv ciB1cyB0byBhY2hpZXZlIHJvdWdoIGNvbnNlbnN1cz8gTWF5YmUuIElNSE8gLQ0KPj4+Pj4+d29y dGgNCj4+Pj4+PiBmaW5kaW5nIG91dC4NCj4+Pj4+Pg0KPj4+Pj4+IE9uIFNhdCwgT2N0IDE4LCAy MDE0IGF0IDU6MDggUE0sIEFsZXhhbmRyZSBHT1VBSUxMQVJEDQo+Pj4+Pj4gPGFnb3VhaWxsYXJk QGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICsxIHRvIG5vdCBoYXZpbmcgTVRJ IGNvZGVjIGRpc2N1c3Npb24gdW5sZXNzIHNvbWUgcHJvZ3Jlc3MgaGFzIGJlZW4NCj4+Pj4+Pj5t YWRlDQo+Pj4+Pj4+IG9uIFZQOCBhdCBNUEVHLiBBbnkgbmV3cyBvbiB0aGF0PyBJJ20gc2hhcmlu ZyBoYXJhbGQncyAgZmVlbGluZw0KPj4+Pj4+PnRoYXQNCj4+Pj4+Pj50aGVyZQ0KPj4+Pj4+PiB3 YXMgbm8gY2hhbmdlIG9uIHRoZSBtZW1iZXJzIHBvc2l0aW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBP biBGcmksIE9jdCAxNywgMjAxNCBhdCA5OjIyIFBNLCBIYXJhbGQgQWx2ZXN0cmFuZA0KPj4+Pj4+ PiA8aGFyYWxkQGFsdmVzdHJhbmQubm8+IHdyb3RlOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIDEw LzE3LzIwMTQgMTI6MDIgQU0sIEJlcm5hcmQgQWJvYmEgd3JvdGU6DQo+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+PiBPbmUgdGhpbmcgd2UgY291bGQgZG8gaW5zdGVhZCBvZiB3YXN0aW5nIHRpbWUgb24gTVRJ IGlzIHRvDQo+Pj4+Pj4+Pj5hY3R1YWxseQ0KPj4+Pj4+Pj4+IG1ha2UgcHJvZ3Jlc3Mgb24gU2Vj dGlvbnMgNC4yIC0gNC40IG9mIGRyYWZ0LUlFVEYtUlRDV0VCLXZpZGVvLA0KPj4+Pj4+Pj4+c28N Cj4+Pj4+Pj4+PndlIGNvdWxkDQo+Pj4+Pj4+Pj4gYWN0dWFsbHkgaW50ZXJvcGVyYXRlIHJlZ2Fy ZGxlc3Mgb2YgdGhlIGNvZGVjLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGUgYmln IGFyZ3VtZW50IGZvciBhbiBNVEkgaXMgYWN0dWFsbHkgdGhlIG9uZSBzdGF0ZWQgaW4NCj4+Pj4+ Pj4+LW92ZXJ2aWV3OiBJdA0KPj4+Pj4+Pj4gZ3VhcmRzIGFnYWluc3QgaW50ZXJvcGVyYWJpbGl0 eSBmYWlsdXJlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEkgd291bGQgbGlrZSB0byBoYXZlIGFuIGVj b3N5c3RlbSB3aGVyZSBvbmUgY2FuIGZpZWxkIGEgYm94LA0KPj4+Pj4+Pj5jb25uZWN0IGl0DQo+ Pj4+Pj4+PiB0byBldmVyeXRoaW5nIGVsc2UsIGFuZCBydW4gd2VsbCBmb3IgKnNvbWUqIGxldmVs IG9mICJ3ZWxsIiAtIGFuZA0KPj4+Pj4+Pj5JDQo+Pj4+Pj4+PndvdWxkDQo+Pj4+Pj4+PiBwcmVm ZXIgdGhhdCBlY29zeXN0ZW0gdG8gYmUgb25lIHdoZXJlIGl0J3MgcG9zc2libGUgdG8gZmllbGQg dGhlDQo+Pj4+Pj4+PmJveCB3aXRob3V0DQo+Pj4+Pj4+PiBtYWtpbmcgcHJpb3IgYXJyYW5nZW1l bnRzIHdpdGggYW55b25lIGFib3V0IGxpY2Vuc2VzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoaXMg YXJndW1lbnQgaGFzbid0IGNoYW5nZWQgb25lIHdoaXQgc2luY2UgbGFzdCB0aW1lIHdlIGRpc2N1 c3NlZA0KPj4+Pj4+Pj5pdC4NCj4+Pj4+Pj4+IEFuZCBJIGRvbid0IHNlZSBtdWNoIG1vdmVtZW50 IG9uIHRoZSBzcGVjaWZpY3Mgb2YgdGhlIHByb3Bvc2Fscw0KPj4+Pj4+Pj5laXRoZXIuDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gV2UnbGwgaGF2ZSB0byBpbnRlcm9wZXJhdGUgd2VsbCB3aXRoIHRoZSBj b2RlY3Mgd2UgZmllbGQuIFNvIHVzaW5nDQo+Pj4+Pj4+PnNvbWUNCj4+Pj4+Pj4+IHRpbWUgdG8g ZGlzY3VzcyBkcmFmdC1pZXRmLXJ0Y3dlYi12aWRlbyBzZWVtcyB0byBtYWtlIHNlbnNlLiAoQW5k DQo+Pj4+Pj4+PjQuMSBpc24ndA0KPj4+Pj4+Pj4gZmluaXNoZWQgZWl0aGVyLiBUaGVyZSdzIG9u ZSBzZW50ZW5jZSB0aGF0IG5lZWRzIHRvIGJlIHJlbW92ZWQuKQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IEkgd291bGRuJ3Qgc2F5IEknZCBiZSBoYXBweSB0byBub3QgZGlzY3VzcyB0aGlzIGluIEhvbm9s dWx1LiBCdXQNCj4+Pj4+Pj4+SSdkDQo+Pj4+Pj4+PiBwcmVmZXIgdG8gcmUtZGlzY3VzcyBiYXNl ZCBvbiB0aGUga25vd2xlZGdlIHRoYXQgc29tZSBzaWduaWZpY2FudA0KPj4+Pj4+Pj5wbGF5ZXJz DQo+Pj4+Pj4+PiBoYXZlIGFjdHVhbGx5IGNoYW5nZWQgdGhlaXIgbWluZHMuDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gQXQgdGhlIG1vbWVudCwgSSBkb24ndCBzZWUgc2lnbnMgdGhhdCBhbnkgb2YgdGhl IHBvbGwgcmVzcG9uZGVudHMNCj4+Pj4+Pj4+aGF2ZQ0KPj4+Pj4+Pj4gc2FpZCAiSSBoYXZlIGNo YW5nZWQgbXkgbWluZCIuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSGFyYWxkDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IE9uIE9jdCAxNiwgMjAxNCwgYXQgMjoyOCBQTSwgTWFydGluIFRob21zb24NCj4+Pj4+Pj4+ Pj4gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+PiBPbiAxNiBPY3RvYmVyIDIwMTQgMTQ6MTcsIE1hdHRoZXcgS2F1Zm1hbiA8bWF0dGhld0Bt YXR0aGV3LmF0Pg0KPj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+PiBBbmQgdGhhdCdzIGJl Y2F1c2Ugc29tZXRoaW5nIHN1YnN0YW50aXZlIGhhcyBjaGFuZ2VkLCBvciBzaW1wbHkNCj4+Pj4+ Pj4+Pj4+IGJlY2F1c2UNCj4+Pj4+Pj4+Pj4+IHdhc3RpbmcgdGhlIFdHIHRpbWUgb24gdGhpcyBh Z2FpbiBpcyBtb3JlIGVudGVydGFpbmluZyB0aGFuDQo+Pj4+Pj4+Pj4+PmFjdHVhbGx5DQo+Pj4+ Pj4+Pj4+PiBmaW5pc2hpbmcgYSBzcGVjaWZpY2F0aW9uIHRoYXQgY2FuIGJlIGluZGVwZW5kZW50 bHkgaW1wbGVtZW50ZWQNCj4+Pj4+Pj4+Pj4+YnkNCj4+Pj4+Pj4+Pj4+IGFsbA0KPj4+Pj4+Pj4+ Pj4gYnJvd3NlciB2ZW5kb3JzPyAoQSBzcGVjaWZpY2F0aW9uIHRoYXQgd2UgYXJlIG5vd2hlcmUg bmVhcg0KPj4+Pj4+Pj4+Pj5oYXZpbmcsDQo+Pj4+Pj4+Pj4+PiBhcyBmYXIgYXMNCj4+Pj4+Pj4+ Pj4+IEkgY2FuIHRlbGwpDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFBlcnNvbmFsbHksIEkndmUg Zm91bmQgdGhlIHJlcHJpZXZlIGZyb20gdGhpcyBmaWdodCByZWZyZXNoaW5nLg0KPj4+Pj4+Pj4+ PkFuZA0KPj4+Pj4+Pj4+PiBpdCB3b3VsZCBhcHBlYXIgdGhhdCB3ZSd2ZSBtYWRlIHNvbWUgcmVh bCBwcm9ncmVzcyBhcyBhIHJlc3VsdC4NCj4+Pj4+Pj4+Pj5JJ2QNCj4+Pj4+Pj4+Pj4gc3VnZ2Vz dCB0aGF0IGlmIHdlIGRvbid0IGhhdmUgbmV3IGluZm9ybWF0aW9uLCB3ZSBjb250aW51ZSB0bw0K Pj4+Pj4+Pj4+PnNwZW5kDQo+Pj4+Pj4+Pj4+IG91ciB0aW1lIHByb2R1Y3RpdmVseS4gIElmIHdl IGNhbid0IGZpbmQgdG9waWNzIHRvIG9jY3VweSBvdXINCj4+Pj4+Pj4+Pj5tZWV0aW5nDQo+Pj4+ Pj4+Pj4+IGFnZW5kYSB0aW1lLCB0aGVuIG1heWJlIHdlIGNhbiBmcmVlIGFuIGFnZW5kYSBzbG90 Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+ Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+PiBydGN3ZWIgbWFpbGlu ZyBsaXN0DQo+Pj4+Pj4+Pj4gcnRjd2ViQGlldGYub3JnDQo+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+Pj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS0NCj4+Pj4+Pj4gQWxleC4g R291YWlsbGFyZCwgUGhELCBQaEQsIE1CQQ0KPj4+Pj4+Pg0KPj4+Pj4+PiANCj4+Pj4+Pj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4+Pj4+Pi0NCj4+Pj4+Pj4tDQo+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0NCj4+Pj4+ Pj4gQ1RPIC0gVGVtYXN5cyBDb21tdW5pY2F0aW9ucywgUydwb3JlIC8gTW91bnRhaW4gVmlldw0K Pj4+Pj4+PiBQcmVzaWRlbnQgLSBDb1NNbyBTb2Z0d2FyZSwgQ2FtYnJpZGdlLCBNQQ0KPj4+Pj4+ Pg0KPj4+Pj4+PiANCj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pi0NCj4+Pj4+Pj4tDQo+Pj4+ Pj4+LS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4gc2cubGlua2VkaW4uY29tL2Fnb3VhaWxsYXJkDQo+ Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+ Pj4+Pj4gcnRjd2ViQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViDQo+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pj4gLS0NCj4+Pj4+PiBKb25hdGhhbiBSb3NlbmJlcmcsIFBoLkQuDQo+Pj4+Pj4gamRyb3NlbkBq ZHJvc2VuLm5ldA0KPj4+Pj4+IGh0dHA6Ly93d3cuamRyb3Nlbi5uZXQNCj4+Pj4+Pg0KPj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4g cnRjd2ViIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+Pj4+Pj4NCj4+Pj4+DQo+ Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IC0tDQo+Pj4+IEFsZXguIEdvdWFpbGxhcmQsIFBoRCwgUGhE LCBNQkENCj4+Pj4gDQo+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4tDQo+Pj4+LQ0KPj4+Pi0tLS0t LS0tLS0tDQo+Pj4+IENUTyAtIFRlbWFzeXMgQ29tbXVuaWNhdGlvbnMsIFMncG9yZSAvIE1vdW50 YWluIFZpZXcNCj4+Pj4gUHJlc2lkZW50IC0gQ29TTW8gU29mdHdhcmUsIENhbWJyaWRnZSwgTUEN Cj4+Pj4gDQo+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4tDQo+Pj4+LQ0KPj4+Pi0tLS0tLS0tLS0t DQo+Pj4+IHNnLmxpbmtlZGluLmNvbS9hZ291YWlsbGFyZA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBy dGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4+Pg0KPj4+DQo+Pj4NCj4+Pg0K Pj4+LS0gDQo+Pj4iVGhvc2Ugd2hvIHdvdWxkIGdpdmUgdXAgRXNzZW50aWFsIExpYmVydHkgdG8g cHVyY2hhc2UgYSBsaXR0bGUNCj4+PlRlbXBvcmFyeSBTYWZldHkgZGVzZXJ2ZSBuZWl0aGVyICBM aWJlcnR5IG5vciBTYWZldHkuIg0KPj4+LS0gQmVuamFtaW4gRnJhbmtsaW4NCj4+Pg0KPj4+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PnJ0Y3dlYiBt YWlsaW5nIGxpc3QNCj4+PnJ0Y3dlYkBpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+cnRjd2ViQGll dGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+ DQoNCg== From nobody Thu Oct 23 10:12:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5DC1ACE09 for ; Thu, 23 Oct 2014 10:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO74dbAGjwJh for ; Thu, 23 Oct 2014 10:12:07 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02861ACD9E for ; Thu, 23 Oct 2014 10:12:07 -0700 (PDT) Received: from [192.168.1.119] (fs5.wan.abq.citylinkwireless.net [216.243.124.18]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C1FF8F226E for ; Thu, 23 Oct 2014 10:12:06 -0700 (PDT) Message-ID: <544936E5.2040909@mozilla.com> Date: Thu, 23 Oct 2014 10:12:05 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ds-fL0TI0HRpOuBtjrgBd6B2Kr8 Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 17:12:10 -0000 Makaraju, Maridi Raju (Raju) wrote: > OPUS does have a built-in FEC so no need for red+ulpfec. As discussed previously on this list [1] the built-in FEC only covers the SILK layer. Existing codec-agnostic mechanisms were perfectly adequate for protecting CELT-mode packets, so we didn't invent something new. [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html From nobody Thu Oct 23 10:20:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9281AD41E for ; Thu, 23 Oct 2014 10:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIP8_hRhQDG8 for ; Thu, 23 Oct 2014 10:20:12 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFF51AD428 for ; Thu, 23 Oct 2014 10:20:00 -0700 (PDT) Received: from [192.168.1.119] (fs5.wan.abq.citylinkwireless.net [216.243.124.18]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 79E7AF23D8 for ; Thu, 23 Oct 2014 10:20:00 -0700 (PDT) Message-ID: <544938BF.2010807@mozilla.com> Date: Thu, 23 Oct 2014 10:19:59 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> <54491CCB.5090007@gmail.com> In-Reply-To: <54491CCB.5090007@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VcoTQIUL_z0NdSkdFmutj5XJ-Ao Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 17:20:17 -0000 Sergio Garcia Murillo wrote: >> substantial (and there are a number of other problems that RED solves >> there, as discussed at the last meeting). >> > Could you elaborate please? See slide 4 of . I was particularly thinking of the issues with bundle, which do not apply to RFC 2198 RED (which I pointed out at the mic). From nobody Thu Oct 23 12:29:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEECC1ACEF4 for ; Thu, 23 Oct 2014 12:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMwMNPHR-usT for ; Thu, 23 Oct 2014 12:29:10 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E954D1A19E2 for ; Thu, 23 Oct 2014 12:29:06 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id E20173CC51C0; Thu, 23 Oct 2014 19:29:02 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9NJT0FS021112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 15:29:05 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 15:29:01 -0400 From: "Makaraju, Maridi Raju (Raju)" To: "Timothy B. Terriberry" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw85NsDgAD8OICAAFA5gP//4SjA Date: Thu, 23 Oct 2014 19:29:00 +0000 Message-ID: References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> <544936E5.2040909@mozilla.com> In-Reply-To: <544936E5.2040909@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WaqrDd-zLgDclcBiY3tuf4wO8U4 Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 19:29:12 -0000 >=20 > Makaraju, Maridi Raju (Raju) wrote: > > OPUS does have a built-in FEC so no need for red+ulpfec. >=20 > As discussed previously on this list [1] the built-in FEC only covers > the SILK layer. Existing codec-agnostic mechanisms were perfectly > adequate for protecting CELT-mode packets, so we didn't invent something > new. >=20 > [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html [Raju] Thanks and appreciate the reference. From nobody Thu Oct 23 12:32:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819121ACEB3 for ; Thu, 23 Oct 2014 12:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO_sKiy5ww25 for ; Thu, 23 Oct 2014 12:32:36 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44801ACFC5 for ; Thu, 23 Oct 2014 12:32:15 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wn1so1270760obc.6 for ; Thu, 23 Oct 2014 12:32:15 -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; bh=O2aU79u5sjIz3YkMPY8zpmrFq6EGOrH2sqAmCvRpA/s=; b=hue6XxUmmndkJdhgb3NPEJt9nPHbZuZSuDqIuKYLcnpgWZbIhf/ivY/5R8wlooDqdR a5T/I4aR7PeHZQ/7bnPemQP9E9LUC/eZCU2QHC/yBbSgnockNM2WwhA0DZFSyWo9BBHA EqHGCdJgIYQKVvh0hHk/SBnhy9NqI5wgYgHuz2JUyn6vrho5Aoy5IJeABF2CXCCOE9x0 VjEgCRDA++OXbKrqpnfWD9mzPlknA9oCSNwwRH2S0EwF1bXpzPBZkuf7/YhVVhF5U6tt RswhEkH0UGCDgRn51dGJ/nNJYEHjJ36JaHs3/pU+gnrw0dlN60PM7Yl8mn+yWhTvpGeQ PJEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=O2aU79u5sjIz3YkMPY8zpmrFq6EGOrH2sqAmCvRpA/s=; b=V70b4f5VBm/OMPBdlxnrG+BwJhpgokyzboKO6j6O+o77pjy65dtzJ/MWNyWnbZZoJE +Yo8Ec5xs6xkAaLCTPYVCLcdiYyRPx6zpXGGx1OXcdEh7tZueAskgKTuwx+NSqUSzmBN cxtFct6qZjgs/rBJU6g39bWGVPPf0zBRbhviVfjDniVu+TPR85/bY9zG8RoeWLVzQqja TB3vGH8VAZEuoXpMjNYRDCQfVUoxJcK32e06D1fXGpL9sAgAgzasgY841ca0Q0hs9NxN W5WG6Vu1tT/8L8LDyLK85zftziWE/oACnw86U/7/D/PqYD2Qtfuhi2eGz9eFJ/r1Yc7y fvNA== X-Gm-Message-State: ALoCoQlmKgboTX7v0C075g/PSeCcIkacAQgqvN9caGbu9mK/pbkfoT7VfwuZ5MGKldzeGiqc1ojz X-Received: by 10.202.199.65 with SMTP id x62mr3511134oif.61.1414092735035; Thu, 23 Oct 2014 12:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.251.230 with HTTP; Thu, 23 Oct 2014 12:31:54 -0700 (PDT) In-Reply-To: <27059BBA-4094-469F-BE8B-156C0692A02F@edvina.net> References: <7594FB04B1934943A5C02806D1A2204B1D4C18C0@ESESSMB209.ericsson.se> <27059BBA-4094-469F-BE8B-156C0692A02F@edvina.net> From: Justin Uberti Date: Thu, 23 Oct 2014 12:31:54 -0700 Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=001a11c17e5e26e40e05061c1fd8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VGr9m5FciI8bscJmw7NPpZP-Unw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 19:32:37 -0000 --001a11c17e5e26e40e05061c1fd8 Content-Type: text/plain; charset=UTF-8 Generally, I think there is a fair amount of confusion about how these various types of TURN servers are going to work. The RETURN draft takes a first stab at defining the interactions here, and ideally it can be adopted as a WG draft and referred to by -transports. On Thu, Oct 23, 2014 at 5:26 AM, Olle E. Johansson wrote: > > On 22 Oct 2014, at 16:57, Benjamin Schwartz wrote: > > FYI, the purpose of the RETURN draft ( > https://tools.ietf.org/html/draft-schwartz-rtcweb-return-03) is to try to > specify the precise interaction and precedence when both the browser and > the application provide TURN servers. (It's not as simple as "one or the > other".) > > I haven't considered the issues related to browser-provided STUN servers, > though. > > Cool! I'll take a look at that. Maybe Haralds draft need to refer to that. > > /O > > > On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> The advantage of an application configuration is that it can be >> dynamically provided/updated, based on location based etc - assuming the >> webpage provider has knowledge about STUN/TURN servers, of course. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. >> Johansson >> Sent: 22 October 2014 17:44 >> To: rtcweb@ietf.org >> Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt >> >> Section 3.4 >> >> " WebRTC browsers MUST support configuration of STUN and TURN servers, >> both from browser configuration and from an application." >> >> >> Should we mention which takes precedence? If configured in the browser, >> start with that server. >> If not use the one provided by the application. >> >> Maybe we should clarify that turn DNS discovery MUST be used to provide >> failover and load balancing. >> >> /O >> _______________________________________________ >> 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 > > --001a11c17e5e26e40e05061c1fd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Generally, I think there is a fair amount of confusion abo= ut how these various types of TURN servers are going to work. The RETURN dr= aft takes a first stab at defining the interactions here, and ideally it ca= n be adopted as a WG draft and referred to by -transports.

On Thu, Oct 23, 2014 at 5:2= 6 AM, Olle E. Johansson <oej@edvina.net> wrote:

On 22 Oct 2014, at 16:57, Benjamin Schwartz <bemasc@webrtc.org> wrote:
FYI, the purpose of the RE= TURN draft (https://tools.ietf.org/html/draft-schwartz-rtcwe= b-return-03) is to try to specify the precise interaction and precedenc= e when both the browser and the application provide TURN servers. =C2=A0(It= 's not as simple as "one or the other".)

I= haven't considered the issues related to browser-provided STUN servers= , though.
Cool! I'll take a look at that= . Maybe Haralds draft need to refer to that.

/O


On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:
Hi,

The advantage of an application configuration is that it can be dynamically= provided/updated, based on location based etc - assuming the webpage provi= der has knowledge about STUN/TURN servers, of course.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. Johansson
Sent: 22 October 2014 17:44
To: rtcweb@ietf.org
Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt

Section 3.4

" WebRTC browsers MUST support configuration of STUN and TURN servers,=
=C2=A0 =C2=A0both from browser configuration and from an application."=


Should we mention which takes precedence? If configured in the browser, sta= rt with that server.
If not use the one provided by the application.

Maybe we should clarify that turn DNS discovery MUST be used to provide fai= lover and load balancing.

/O
_______________________________________________
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


--001a11c17e5e26e40e05061c1fd8-- From nobody Thu Oct 23 22:11:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AA61A88A9 for ; Thu, 23 Oct 2014 22:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jwyzvLLwFX7 for ; Thu, 23 Oct 2014 22:11:22 -0700 (PDT) Received: from relay.mailchannels.net (aso-006-i443.relay.mailchannels.net [23.91.64.124]) by ietfa.amsl.com (Postfix) with ESMTP id C32C81A8883 for ; Thu, 23 Oct 2014 22:11:21 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 403DF27908D for ; Fri, 24 Oct 2014 05:11:19 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.248.11.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.3.2); Fri, 24 Oct 2014 05:11:19 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1414127479528:2378389398 X-MC-Ingress-Time: 1414127479528 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:62779 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XhX9i-0005pr-2O for rtcweb@ietf.org; Fri, 24 Oct 2014 00:11:18 -0500 Message-ID: <5449DF6C.9060301@jesup.org> Date: Fri, 24 Oct 2014 01:11:08 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060700060709010505080802" X-AuthUser: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XHBhpHzvv-C3aFItx1rP4U2dJG8 Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 05:11:25 -0000 This is a multi-part message in MIME format. --------------060700060709010505080802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/20/2014 3:09 AM, Cavigioli, Chris wrote: > > No, not 2 discussions ... but 2 MTI codecs. > > Given: > > -Industry is polarized c. 40% VP8 vs. c. 40% H.264 > > -Unlikely this will change > > -Every single mobile device (100%) of the billions out there running a > mobile OS (iOS, Android, Windows, BB OS, etc) will already support > H.264, AMR-xx since those are MTI for 3GPP and for the OS > > Then: > > -Why not support both: VP8, Opus = web; H.264, AMR/AMR-WB = LTE > > -Every single mobile device and OS already deals with H.264+AMR > licensing for many years. > > -Being royalty free, incrementally adding VP8 and Opus shouldn't be a > major additional impact > I should note that many H.264 HW implementations (or the software driving them) in mobile devices are NOT usable for WebRTC (or for video communication in general). The bugs I've seen..... . You can certify specific sets of hardware or base chipset code, but until they actually get tested *well* in interactive, error-recovery, variable bandwidth use you have no clue if they'll work. (And without such testing, generally the answer would be 'no'). Can you say "IDR to change bitrate"? Learn.... OMX has *many* options, most of which are not supported on a given implementation, which makes generic use 'interesting' when you go past the well-traveled (and still rocky) decode path. So if Mozilla distributes Firefox to Android devices, what are we to do? We can't simply assume the encoder/decoder will work for WebRTC at this point. Even getting streaming video decode to leverage HW decoders was a massive pain with whitelists, blacklists, evil device-specific hacks, etc. It has gotten better over time - but not great. I'll note that for WebRTC we currently support OpenH264 on desktop, and HW H.264 on specific FxOS devices/chipsets/versions (the default for FxOS WebRTC OMX H.264 support is false). As of today we support only VP8 on Android. And I'll echo Bernard's comments about AMR and licensing/open APIs. When did people forget how to edit out irrelevant repetition of old messages? Ah, yes, when everyone started top-replying.... Makes searching archives much less fun. :-/ -- Randell Jesup -- rjesup a t mozilla d o t com --------------060700060709010505080802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/20/2014 3:09 AM, Cavigioli, Chris wrote:

No, not 2 discussions … but 2 MTI codecs. 

Given:

-       Industry is polarized c. 40% VP8 vs. c. 40% H.264

-       Unlikely this will change

-       Every single mobile device (100%) of the billions out there running a mobile OS (iOS, Android, Windows, BB OS, etc) will already support H.264, AMR-xx since those are MTI for 3GPP and for the OS

Then:

-       Why not support both:  VP8, Opus = web; H.264, AMR/AMR-WB = LTE

-       Every single mobile device and OS already deals with H.264+AMR licensing for many years.

-       Being royalty free, incrementally adding VP8 and Opus shouldn’t be a major additional impact


I should note that many H.264 HW implementations (or the software driving them) in mobile devices are NOT usable for WebRTC (or for video communication in general).  The bugs I've seen..... <shudder>.  You can certify specific sets of hardware or base chipset code, but until they actually get tested *well* in interactive, error-recovery, variable bandwidth use you have no clue if they'll work.  (And without such testing, generally the answer would be 'no').  Can you say "IDR to change bitrate"?  Learn....  OMX has *many* options, most of which are not supported on a given implementation, which makes generic use 'interesting' when you go past the well-traveled (and still rocky) decode path.

So if Mozilla distributes Firefox to Android devices, what are we to do?  We can't simply assume the encoder/decoder will work for WebRTC at this point.  Even getting streaming video decode to leverage HW decoders was a massive pain with whitelists, blacklists, evil device-specific hacks, etc.  It has gotten better over time - but not great.

I'll note that for WebRTC we currently support OpenH264 on desktop, and HW H.264 on specific FxOS devices/chipsets/versions (the default for FxOS WebRTC OMX H.264 support is false).  As of today we support only VP8 on Android.

And I'll echo Bernard's comments about AMR and licensing/open APIs.

<gripe> When did people forget how to edit out irrelevant repetition of old messages?  Ah, yes, when everyone started top-replying.... </gripe>  Makes searching archives much less fun.  :-/


-- 
Randell Jesup -- rjesup a t mozilla d o t com
--------------060700060709010505080802-- From nobody Fri Oct 24 16:08:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B11A1B7E; Fri, 24 Oct 2014 16:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD9uX8jmg6Vj; Fri, 24 Oct 2014 16:08:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1774A1A1B5B; Fri, 24 Oct 2014 16:08:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024230804.22063.52332.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 16:08:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9kEtcEVpYGp9bT01klQ6fDQDBL0 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 23:08:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Audio Codec and Processing Requirements Authors : Jean-Marc Valin Cary Bran Filename : draft-ietf-rtcweb-audio-07.txt Pages : 6 Date : 2014-10-24 Abstract: This document outlines the audio codec and processing requirements for WebRTC client application and endpoint devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-audio-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 24 16:32:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E809A1A1ABC for ; Fri, 24 Oct 2014 16:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALtkxJTFwCaa for ; Fri, 24 Oct 2014 16:32:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436161A1A5D for ; Fri, 24 Oct 2014 16:32:43 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9ONWcwx073238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2014 18:32:39 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <544AE196.6080907@nostrum.com> Date: Fri, 24 Oct 2014 18:32:38 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Stephan Wenger , Watson Ladd , Alexandre GOUAILLARD References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dYcbwnNM88l4TSYkZnv1TrKzArc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 23:32:45 -0000 On 10/22/14 14:45, Stephan Wenger wrote: > I have to make one correction in the light of information that has > surfaced at the MPEG meeting currently ongoing in Strasbourg. (I’m not at > that meeting this time, but a colleague is and she briefed me.) > Nokia has made MPEG and ISO/IEC officially aware that they are not willing > to license essential patents under RAND terms. For those with MPEG > document access, please see M34917. The official declaration is dated > 9/19/2014, and is not yet available from the respective databases, as ISO > is apparently changing its recordation infrastructure. Thanks for the update. That's actually even more interesting than it first appears to be. The official rationale previously offered by Nokia was that the refusal to license patents [0] for VP8 was that VP8 had not been through an appropriate standards process [1]. The fact that Nokia is now using those same patents to *block* VP8-based work from going through an appropriate standards process pretty clearly exposes that claim as false. This isn't aimed at ensuring "open and collaborative efforts for standardization": this is aimed at suppressing technology. To be clear, my position remains that either VP8 or H.264 would be a suitable MTI, and (although not my preference) I would accept a situation in which both are required. Which is to say that I don't really have much at stake in the MTI conversation (as long as we do eventually do something to guarantee interop). But it does seem that Nokia isn't being forthcoming about its motives here, and I find that pretty distasteful. I would have preferred silence over lies. > My understanding of the joint ITU/ISO/IEC patent policy is that no > standard can be issued that has a type 3 declaration against it. To the > best of my knowledge, ISO has no established procedure how to deal with > type 3 (non-RAND) declarations and still keep the standard project going. > Unlike, for example, W3C and its Patent Advisory Groups. > The declaration does not list specific patents. To the best of my > knowledge, such info is not required (only desired) for ISO and IEC > standardization work--one of the few differences in patent policy > guidelines between ITU and ISO/IEC. > Therefore, I have to row back on my previous statement of likeliness of > having an ISO number for VP8 anytime soon. At this point, I just don’t > know whether, if ever, that will happen. I find the ISO policy as stated to be curious -- if it doesn't require citing patents, and categorically refuses to issue specs with type 3 declarations, I could effectively reduce the ISO output to zero by mechanically claiming a type 3 declaration on every specification under development. /a ____ [0] For absolute clarity, I make no assertion one way or another about the applicability of such patents to VP8. [1] As quoted in uncountably many publications: "Nokia believes that open and collaborative efforts for standardization are in the best interests of consumers, innovators and the industry as a whole. We are now witnessing one company attempting to force the adoption of its proprietary technology, which offers no advantages over existing, widely deployed standards such as H.264 and infringes Nokia's intellectual property. As a result, we have taken the unusual step of declaring to the Internet Engineering Task Force that we are not prepared to license any Nokia patents which may be needed to implement its RFC6386 specification for VP8, or for derivative codecs." From nobody Fri Oct 24 17:00:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179A41A1BB4 for ; Fri, 24 Oct 2014 17:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I__yMaiQRGc for ; Fri, 24 Oct 2014 17:00:14 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58481A1C03 for ; Fri, 24 Oct 2014 17:00:12 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so2077064wgh.33 for ; Fri, 24 Oct 2014 17:00:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=lpKAv85V+bEz6MGDF32hET9Z7PFNxCG/KZ8Xe43RGRQ=; b=JaxCmqY6YphmCwGjixUKXPdt0BI9yIN+JM1eQX+m9M9k6fhieTNJXmSssh8Qm+E6Iv MwCz/Ey8sKmGjgl6iwiFDl6Ek/JMr6qhH41AH319fTlCvt9/1RtsTvyFoEmFtBlLMU+D sCbF35zjjgcOUsjHpRVquZhRNGqEoKdTX53DZ/RZzO38o0cwMx2PoPN7mMciyblC/4hl S38/pKvKuHH9fqlyaiWAbpi7l/8qv3cwMfJOHJ+7ify35hKu8YxQFMpcBUcZR1DN28Uv daIrPS7bhdvgFU4Yhqq+BoWCpCaD1oDx/68GVMoWR31HXbvNr61L7D8g7E2Vm74h77RP oFhQ== X-Gm-Message-State: ALoCoQmZHxNqCczXX3+jvB0GW6ecLDqjPF6vyUJ3p/Eht3RGVQiKkNfv+Ytj48vXawM93bPGIQNP X-Received: by 10.180.107.69 with SMTP id ha5mr6897795wib.69.1414195211249; Fri, 24 Oct 2014 17:00:11 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com. [74.125.82.51]) by mx.google.com with ESMTPSA id bi7sm3556975wib.17.2014.10.24.17.00.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 17:00:10 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so2098688wgh.22 for ; Fri, 24 Oct 2014 17:00:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.88.102 with SMTP id bf6mr6929699wib.43.1414195209743; Fri, 24 Oct 2014 17:00:09 -0700 (PDT) Received: by 10.216.176.65 with HTTP; Fri, 24 Oct 2014 17:00:09 -0700 (PDT) Date: Fri, 24 Oct 2014 20:00:09 -0400 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428ab21eb58a050633fb98 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-dBz1M-3EgdoGxzvnA6wyzxfqHc Subject: [rtcweb] Comments regarding draft-ietf-rtcweb-audio-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 00:00:17 -0000 --f46d04428ab21eb58a050633fb98 Content-Type: text/plain; charset=UTF-8 In section 3, draft states that: "WebRTC clients are REQUIRED to be able to generate and consume the following events" followed by list of RFC4733 events. What does it mean by "consume"? Does it mean receive without failure, while ignoring its contents or actually processing the events and exposing them to the end point user in some way? Supported RFC4733 event list does not match events listed in section 6.2.2 W3C TR (http://www.w3.org/TR/webrtc/#methods-4). W3C also lists support for DTMF digits A through D. Should the document state the duration and gap recommendations for RFC 4733 tones from section 6.2.2 of W3C document? I did not know there is a consensus on must implement of CN. Regards, _____________ Roman Shpount --f46d04428ab21eb58a050633fb98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In section 3, draft states that: "WebRTC clients are REQUIRED = to be able to generate and consume the=C2=A0following events" followed b= y list of=C2=A0RFC4733 events. What does it mean by "consume"? Does= it mean receive without failure, while ignoring its contents or actually p= rocessing the events and exposing them to the end point user in some way?= =C2=A0

Supported=C2=A0RFC= 4733=C2=A0event list does not match events listed in section 6.2.2 W= 3C TR (http://www.w3.org= /TR/webrtc/#methods-4). W3C also lists support for DTMF digits A throug= h D.

Should the document state the du= ration and gap recommendations for RFC 4733 tones from section 6.2.2 of W3C= document?

I did not know ther= e is a consensus on must implement of CN.

Regards,
____= _________
Roman Shpount
--f46d04428ab21eb58a050633fb98-- From nobody Fri Oct 24 18:53:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978261A1BE4 for ; Fri, 24 Oct 2014 18:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF6sPInOpZ6y for ; Fri, 24 Oct 2014 18:53:48 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id CCC6E1A1B6C for ; Fri, 24 Oct 2014 18:53:46 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 24 Oct 2014 18:53:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,784,1406617200"; d="scan'208,217";a="595667030" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by orsmga001.jf.intel.com with ESMTP; 24 Oct 2014 18:53:45 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 24 Oct 2014 18:53:45 -0700 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.180]) by FMSMSX110.amr.corp.intel.com ([10.18.116.10]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 18:53:45 -0700 From: "Cavigioli, Chris" To: Leon Geyser Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP69ySvH0vdbAWv0eULyOYAeS/S5w4ZQqA//+vamCABWG9QIAAysqAgAHUCNA= Date: Sat, 25 Oct 2014 01:53:44 +0000 Message-ID: References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <54442128.6070009@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.107] Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD240084E9Dfmsmsx118amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vxQHvmgxOZBIMCl-V6h9N7aTI-k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 01:53:53 -0000 --_000_E36D1A4AE0B6AA4091F1728D584A6AD240084E9Dfmsmsx118amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RVZTIHN1cHBvcnRzIEFNUi1XQiBmdW5jdGlvbmFsaXR5Og0KaHR0cDovL3d3dy5ldHNpLm9yZy9k ZWxpdmVyL2V0c2lfdHMvMTI2NDAwXzEyNjQ5OS8xMjY0NDYvMTIuMDAuMDBfNjAvdHNfMTI2NDQ2 djEyMDAwMHAucGRmDQoNCg0KRnJvbTogTGVvbiBHZXlzZXIgW21haWx0bzpsZ2V5c2VyQGdtYWls LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIzLCAyMDE0IDc6NTggQU0NClRvOiBDYXZp Z2lvbGksIENocmlzDQpDYzogSGFyYWxkIEFsdmVzdHJhbmQ7IEJlcm5hcmQgQWJvYmE7IHJ0Y3dl YkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFBsYW4gZm9yIE1USSB2aWRlbyBjb2Rl Yz8NCg0KSW4gc2VjdGlvbiAnNiBVc2UgQ2FzZXMnIGl0IHNlZW1zIGxpa2UgdGhlcmUgaXNuJ3Qg YW55IHRyYW5zY29kaW5nIHJlcXVpcmVkIGJldHdlZW4gQU1SLVdCIDwtPiBFVlMNCkNhbiBhbiBB TVItV0IgZGVjb2RlciBkZWNvZGUgYW4gRVZTIHN0cmVhbT8NCg0KT24gMjMgT2N0b2JlciAyMDE0 IDEyOjE1LCBDYXZpZ2lvbGksIENocmlzIDxjaHJpcy5jYXZpZ2lvbGlAaW50ZWwuY29tPG1haWx0 bzpjaHJpcy5jYXZpZ2lvbGlAaW50ZWwuY29tPj4gd3JvdGU6DQpUaGUgR1NNQSB3aGl0ZSBwYXBl ciBoYXMgYmVlbiBwdWJsaXNoZWQuICBEb3dubG9hZCBhIGNvcHkgaGVyZTogIGh0dHA6Ly93d3cu Z3NtYS5jb20vbmV3c3Jvb20vd2VicnRjLWNvZGVjcy1kcmFmdC12MS0zLw0KDQpOb3RlOiBUcmFu c2NvZGluZyBjYW4gYmUgYXZvaWRlZCBieSBuZWdvdGlhdGluZyBvcHRpb25hbCBjb2RlY3MgYW5k IGZpbmRpbmcgYSBtYXRjaGluZyBwYWlyLiAgVGhlIEdTTUEgd2hpdGUgcGFwZXIgZG9lc27igJl0 IGZvY3VzIG9uIHRoYXQgY2FzZSwgYnV0IGluc3RlYWQgc3BlY2lmaWNhbGx5IGhpZ2hsaWdodHMg dGhlIHNjZW5hcmlvIHdoZXJlIGEgcHVyZSBXZWJSVEMgZW5kcG9pbnQgaXMgY29tbXVuaWNhdGlu ZyB3aXRoIGEgcHVyZSAzR1BQIExURSBWb0xURS9WaUxURSBJTVMgZW5kcG9pbnQsIGFzc3VtaW5n IGVhY2ggZW5kcG9pbnQgT05MWSBoYXMgYWNjZXNzIHRvIHRoZSBNVEkgY29kZWNzIGluIGl0cyBy ZXNwZWN0aXZlIGRvbWFpbi4gIEluIHRoYXQgY2FzZSwgdGhlIG5ldHdvcmsgaXMgcmVzcG9uc2li bGUgdG8gdHJhbnNjb2RlIGJldHdlZW4gKE9wdXMgb3IgRy43MTEsIDxXZWJSVEMgTVRJIHZpZGVv IGNvZGVjIFRCRD4pIGFuZCAoQU1SIG9yIEFNUi1XQiwgSC4yNjQpLg0KDQpGcm9tOiBydGN3ZWIg W21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQ2F2aWdpb2xpLCBDaHJpcw0KU2VudDogU3VuZGF5LCBPY3Rv YmVyIDE5LCAyMDE0IDY6MjAgUE0NClRvOiBIYXJhbGQgQWx2ZXN0cmFuZDsgQmVybmFyZCBBYm9i YQ0KDQpDYzogcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gUGxhbiBmb3IgTVRJIHZpZGVvIGNvZGVjPw0KDQpIYXJhbGQgc2FpZDoN CuKAnFdlIG1hZGUgdGhlIG1pc3Rha2Ugb2YgaGF2aW5nIGFuIE1USSBkaXNjdXNzaW9uIHByZXZp b3VzbHkgd2l0aCBub3QgZW5vdWdoIGRldGFpbHMgb24gdGhhdCBzdWJqZWN04oCm4oCdDQoNCldl IGRpZG7igJl0IGhhdmUgcXVhbnRpdGF0aXZlIGRhdGEgZWFybGllciBmb3IgYSBkYXRhLWRyaXZl biBkZWNpc2lvbi4gIEZ1dHVyZSBXZWIg4oCTIExURSBpbnRlcm9wIGlzIGltcG9ydGFudC4gIEEg Z3JvdXAgb2YgdXMgaW4gR1NNQSBoYXZlIGJlZW4gbG9va2luZyBhdCBXZWJSVEMgaW50ZXJvcCB3 aXRoIExURSAod2hlcmUgM0dQUCAvIEdTTUEgZGVmaW5lZCBJTVMtYmFzZWQgdm9pY2UvdmlkZW8v bWVzc2FnaW5nKSwgc3BlY2lmaWNhbGx5IGxvb2tpbmcgYXQgdXNlciBleHBlcmllbmNlIGltcGFj dCBvZiBsYXRlbmN5IGludHJvZHVjZWQgYnkgYWRkZWQgaW4tbmV0d29yayB0cmFuc2NvZGluZy4g IEdTTUEgaGFzIGFwcHJvdmVkIHRoZSB3aGl0ZXBhcGVyIGFuZCBpdCBpcyBiZWluZyBwcmVwYXJl ZCBmb3IgcHVibGljIGRpc3RyaWJ1dGlvbi4NCg0KV2ViUlRDIOKAkyBMVEUgdHJhbnNjb2Rpbmcg aXMgbm93IE1BTkRBVE9SWSBiZWNhdXNlIG9mIOKAnFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJv Y2Vzc2luZyBSZXF1aXJlbWVudHPigJ0uIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLWF1ZGlvLTA1LCB3aGVyZSBNVEkgYXVkaW8gY29kZWNzIGluIFdlYlJUQyBh bmQgaW4gTFRFIGFyZSBkaXNzaW1pbGFyLiAgVGh1cywgUkVHQVJETEVTUyBvZiB0aGUgdmlkZW8g Y29kZWNzLCB0aGVyZSBpcyBhbHJlYWR5IGEgc2lnbmlmaWNhbnQgZGVncmFkYXRpb24gaW1wb3Nl ZCBvbiBXZWIg4oCTIExURSBsaW5rcyBpZiBvbmx5IE1USSBjb2RlY3MgYXJlIHVzZWQuICBUaGUg b25seSBzeXN0ZW1zIHRvIGF2b2lkIHRoaXMgYXJlIHRob3NlIHdoaWNoIGltcGxlbWVudCBPUFRJ T05BTCBhdWRpbyBjb2RlY3MgdG8gYmUgdHJhbnNjb2Rlci1mcmVlIHdpdGggTFRFLiAgVGhlIHNh bWUgY2FuIGFwcGx5IGZvciB2aWRlbyBjb2RlY3MuDQoNClRoZSBHU01BIHdoaXRlcGFwZXIgcmVm ZXJzIHRvOg0KDQoxLiAgICAgUXVhbnRpdGF0aXZlIHZvaWNlLW92ZXItTFRFIChWb0xURSkgZGVs YXkgbGltaXRzIHdlcmUgYWdyZWVkLXRvIGJ5IDNHUFAgU0E0IGluIEF1Z3VzdCAyMDE0LiAgVG8g cGFyYXBocmFzZSwgcGVyZm9ybWFuY2Ugb2JqZWN0aXZlcyBmb3IgbWF4aW11bSBWb0xURSBkZXZp Y2UgZGVsYXlzIGluIGVycm9yIGFuZCBqaXR0ZXIgZnJlZSBjb25kaXRpb25zIGFuZCBBTVIgc3Bl ZWNoIGNvZGVjIG9wZXJhdGlvbiwgdGhlIHN1bSBvZiB0aGUgVUUgZGVsYXlzIGluIHNlbmRpbmcg YW5kIHJlY2VpdmluZyBkaXJlY3Rpb25zIChUUyArIFRSKSBzaG91bGQgYmUg4omkIDE1MG1zLiBJ ZiB0aGlzIHBlcmZvcm1hbmNlIG9iamVjdGl2ZSBjYW5ub3QgYmUgbWV0LCB0aGUgc3VtIG9mIHRo ZSBVRSBkZWxheXMgaW4gc2VuZGluZyBhbmQgcmVjZWl2aW5nIGRpcmVjdGlvbnMgKFRTICsgVFIp IHNoYWxsIGluIGFueSBjYXNlIGJlIOKJpCAxOTBtcy4NCg0KMi4gICAgIE9QVVMg4oCTIEFNUiB0 cmFuc2NvZGluZyBhZGRzIGFuIGFkZGl0aW9uYWwgMjExLjUgbXMgaW1wbGVtZW50YXRpb24tYWdu b3N0aWMgKFRTICsgVFIpIGRlbGF5LCBpbmNsdWRpbmcgNDAgbXMgZm9yIGppdHRlciBidWZmZXIg YW5kIDQwIG1zIGZvciBkaXNjb250aW51b3VzIHJlY2VwdGlvbiAoRFJYKS4NCg0KMy4gICAgIFRv IHB1dCB0aGVzZSBudW1iZXJzIGluIHBlcnNwZWN0aXZlLCBpdCBpcyBpbiBnZW5lcmFsIGRlc2ly YWJsZSB0byBtaW5pbWl6ZSBVRSBkZWxheXMgdG8gZW5zdXJlIGxvdyBlbm91Z2ggZW5kLXRvLWVu ZCBkZWxheXMgYW5kIGhlbmNlIGEgZ29vZCBjb252ZXJzYXRpb25hbCBleHBlcmllbmNlLiAgSW5j cmVhc2luZyBkZWxheSBjYXVzZXMgcGVvcGxlIHRvIGRvdWJsZS10YWxrIG1ha2luZyBjb252ZXJz YXRpb25zIGluY3JlYXNpbmdseSBmcnVzdHJhdGluZy4gIEd1aWRhbmNlIHRvIHN0YXkgYmVsb3cg NDAwIG1zIG1heGltdW0gb25lLXdheSBkZWxheSBpcyBmb3VuZCBpbiBJVFUtVCBSZWNvbW1lbmRh dGlvbiBHLjExNCBhbmQgdGhlIGNvbXB1dGF0aW9uYWwgRS1tb2RlbCBpcyBpbiBJVFUtVCBSZWNv bW1lbmRhdGlvbiBHLjEwNy4NCg0KVGhpcyBpcyBhIGNvbXBsZXggdG9waWMgd2l0aCBtYW55IG5l dHdvcmsgZmFjdG9ycyBpbiBwbGF5LiAgTFRFIG9wZXJhdG9ycyBpbiAzR1BQIHNlZWsgVUUgZGVs YXlzIChUUyArIFRSKSBhcm91bmQgMTUwIG1zLiAgQWRkaW5nIE9QVVMg4oCTIEFNUiB0cmFuc2Nv ZGluZyBpbiB0aGUgbmV0d29yayBpbXBvc2VzIGFuIGFkZGl0aW9uYWwgMjExLjUgbXMgb24gdG9w IG9mIHRoYXQsIGp1c3QgZm9yIGF1ZGlvLiAgT3B0aW9uYWxseSB1c2luZyBBTVIgaW4gV2ViUlRD LCB0aG9zZSAyMTEuNSBtcyBjYW4gYmUgZWxpbWluYXRlZCwgZGVsaXZlcmluZyBhIHN1cGVyaW9y IGVuZC11c2VyIGV4cGVyaWVuY2UuDQoNCkNPTkNMVVNJT046ICByZWdhcmRsZXNzIG9mIE1USSBj b2RlYyBjaG9pY2VzIGluIFdlYlJUQywgdG8gcHJvdmlkZSBhIGdvb2QgV2ViUlRDIOKAkyBMVEUg aW50ZXJvcCBleHBlcmllbmNlLCBlbWVyZ2luZyBXZWJSVEMgc3lzdGVtcyBtdXN0IGFjY29tbW9k YXRlIE1USSBjb2RlY3MgYWxyZWFkeSBkZXBsb3llZCBpbiB0aGUgTFRFIGRvbWFpbiBhbmQgaW4g bW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1zLCBuYW1lbHkgQU1SL0FNUi1XQiBhbmQgSC4yNjQuDQoN ClBPU0lUSU9OOiAgVG8gYmUgY2xlYXIsIHNldmVyYWwgSW50ZWwgU29DcyBsYXVuY2hlZCBhdCBN V0MgdGhpcyB5ZWFyIGZvciBzbWFydHBob25lcyBhbmQgdGFibGV0cyBzdXBwb3J0IGJvdGggVlA4 IGFuZCBILjI2NCBoYXJkd2FyZSBlbmNvZGUgYW5kIGRlY29kZSDigJMgc28gSW50ZWwgaXMgY29k ZWMtbmV1dHJhbCBpbiB0aGlzIE1USSBkZWJhdGUuICBBZGRpdGlvbmFsbHksIEludGVsIGhhcyBo aWdoLXBlcmZvcm1hbmNlIHNvbHV0aW9ucyBmb3IgdHJhbnNjb2RpbmcuICBIb3dldmVyLCB3ZSB3 aXNoIHRvIGluZm9ybSB0aGUgaW5kdXN0cnksIHdpdGggcXVhbnRpdGF0aXZlIGRhdGEsIGFib3V0 IGltcGFjdCB0byBlbmQtdXNlciBleHBlcmllbmNlIG9mIG1hbmRhdGluZyBzdWNoIHRyYW5zY29k aW5nIHNvIElFVEYgY2FuIG1ha2UgYSBkYXRhLWRyaXZlbiBkZWNpc2lvbiBvbiB2aWRlbyBjb2Rl Y3MgYXMgd2VsbCBhcyByZWZsZWN0IG9uIHRoZSBpbXBhY3Qgb2YgYWxyZWFkeSBoYXZpbmcgbWFu ZGF0ZWQgdHJhbnNjb2Rpbmcgb24gdGhlIGF1ZGlvIHNpZGUuDQoNCkNocmlzIENhdmlnaW9saQ0K SW50ZWwgQ29ycCwgU3lzdGVtIEFyY2hpdGVjdHVyZSBhbmQgUGxhbm5pbmcsIFZpZGVvL011bHRp bWVkaWEsIE1vYmlsZSBhbmQgQ29tbXVuaWNhdGlvbnMgR3JvdXAgKE1DRykNCisxICg0MTUpIDI1 NC00NTQ1PHRlbDolMkIxJTIwJTI4NDE1JTI5JTIwMjU0LTQ1NDU+IG1vYmlsZQ0KKzEgKDQwOCkg NjUzLTgzNDg8dGVsOiUyQjElMjAlMjg0MDglMjklMjA2NTMtODM0OD4gZGVzaw0KKzEgKDQwOCkg ODg0LTI0MDA8dGVsOiUyQjElMjAlMjg0MDglMjklMjA4ODQtMjQwMD4gZmF4DQpUaGlzIGUtbWFp bCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiAgQW55IHJldmlldyBvciBk aXN0cmlidXRpb24gYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSBhbGwgY29waWVzLg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlcm5hcmQgQWJvYmENClNlbnQ6IFN1bmRheSwgT2N0 b2JlciAxOSwgMjAxNCAyOjI5IFBNDQpUbzogSGFyYWxkIEFsdmVzdHJhbmQNCkNjOiBydGN3ZWJA aWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBQ bGFuIGZvciBNVEkgdmlkZW8gY29kZWM/DQoNCkhhcmFsZCBzYWlkOg0KDQoiQmVybmFyZCwNCg0K SSB0aGluayB0aGlzIGlzLCB0byBhIGxhcmdlIGRlZ3JlZSwgY29kZWMgaW5kZXBlbmRlbnQuDQoN CldlIGhhdmUgZGVtb25zdHJhdGVkIGludGVyb3BlcmFiaWxpdHkgb24gVlA4IGJldHdlZW4gRmly ZWZveCBhbmQgQ2hyb21lLCBhbmQgdXNhZ2Ugb2YgdmFyaW91cyBtZWNoYW5pc21zIGZvciBjb25n ZXN0aW9uIGNvbnRyb2wgYW5kIHJlcGFpciBvZiBwYWNrZXQgbG9zcyBiZWluZyBhcHBsaWVkIGlu IGxpdmUgc2VydmljZXMuDQpTbyBpdCBjYW4ndCBiZSBhbGwgYmFkLi4uLi4iDQoNCltCQV0gIEkg YWdyZWUgdGhhdCB0aGUgbGFjayBvZiBpbnRlcm9wZXJhYmlsaXR5IGlzIGxhcmdlbHkgImNvZGVj IGluZGVwZW5kZW50IjogICB0aGF0IGlzLCBpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZGlmZmVy ZW50IG1lY2hhbmlzbXMgZm9yIGNvbmdlc3Rpb24gY29udHJvbCwgcmVwYWlyLCBldGMuIHdpbGwg ZXhoaWJpdCBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLCByZWdhcmRsZXNzIG9mIHRoZSBjb2Rl YyBjaG9zZW4uICAgVGhlIHJlYWwgdGVzdCBmb3IgUlRDV0VCIHdpbGwgYmUgdG8gbW92ZSBiZXlv bmQgImludGVyb3BlcmFiaWxpdHkgb2YgaW1wbGVtZW50YXRpb25zIHNoYXJpbmcgc291cmNlIGNv ZGUiICB0byAiaW50ZXJvcGVyYWJpbGl0eSBvZiBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMs IGJhc2VkIG9uIG9wZW4gc3RhbmRhcmRzIi4NCg0KT24gU3VuLCBPY3QgMTksIDIwMTQgYXQgMToz OCBQTSwgSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJh bGRAYWx2ZXN0cmFuZC5ubz4+IHdyb3RlOg0KT24gMTAvMTkvMjAxNCAwNTo0MyBQTSwgQmVybmFy ZCBBYm9iYSB3cm90ZToNCiJBbmQgaXRzIG9uZSBvZiB0aGUgaXNzdWVzIGhvbGRpbmcgdXAgd2lk ZXIgYWRvcHRpb24gb2YgdGhlIHRlY2hub2xvZ3kiDQoNCltCQV0gU3BlY2lmeWluZyBhbiBNVEkg ZW5jb2Rlci9kZWNvZGVyIGlzIG5vdCBzdWZmaWNpZW50IGZvciBpbnRlcm9wZXJhYmlsaXR5LiAg SXQgaXMgYWxzbyBuZWNlc3NhcnkgdG8gc3BlY2lmeSB0aGUgdHJhbnNwb3J0IGluIGVub3VnaCBk ZXRhaWwgdG8gYWxsb3cgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIHRoYXQgaW50ZXJvcGVy YXRlIHdlbGwgZW5vdWdoIHRvIGJlIHVzYWJsZSBpbiBhIHdpZGUgdmFyaWV0eSBvZiBzY2VuYXJp b3MsIGluY2x1ZGluZyB3aXJlbGVzcyBuZXR3b3JrcyB3aGVyZSBsb3NzIGlzIGNvbW1vbmx5IGV4 cGVyaWVuY2VkLg0KDQpCZXJuYXJkLA0KDQpJIHRoaW5rIHRoaXMgaXMsIHRvIGEgbGFyZ2UgZGVn cmVlLCBjb2RlYyBpbmRlcGVuZGVudC4NCg0KV2UgaGF2ZSBkZW1vbnN0cmF0ZWQgaW50ZXJvcGVy YWJpbGl0eSBvbiBWUDggYmV0d2VlbiBGaXJlZm94IGFuZCBDaHJvbWUsIGFuZCB1c2FnZSBvZiB2 YXJpb3VzIG1lY2hhbmlzbXMgZm9yIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgcmVwYWlyIG9mIHBh Y2tldCBsb3NzIGJlaW5nIGFwcGxpZWQgaW4gbGl2ZSBzZXJ2aWNlcy4NCg0KU28gaXQgY2FuJ3Qg YmUgYWxsIGJhZC4uLi4uDQoNCg0KV2UgbWFkZSB0aGUgbWlzdGFrZSBvZiBoYXZpbmcgYW4gTVRJ IGRpc2N1c3Npb24gcHJldmlvdXNseSB3aXRoIG5vdCBlbm91Z2ggZGV0YWlscyBvbiB0aGF0IHN1 YmplY3QsIHBhcnRpY3VsYXJseSB3aXRoIHJlc3BlY3QgdG8gSC4yNjQuIGRyYWZ0LWlldGYtcnRj d2ViLXZpZGVvIHNlY3Rpb25zIDQuMiAtIDQuNCByZW1haW4gc2tldGNoeSBhdCBiZXN0Lg0KDQpT byBpZiB3ZSBhcmUgdG8gaGF2ZSB0aGUgZGlzY3Vzc2lvbiBhZ2FpbiwgaXQgc2hvdWxkIG9jY3Vy IGluIHRoZSBjb250ZXh0IG9mIGRldGFpbGVkIHNwZWNpZmljYXRpb25zIGFuZCBpbnRlcm9wZXJh YmlsaXR5IHJlcG9ydHMuDQoNCg0KDQoNCg0KT24gU3VuLCBPY3QgMTksIDIwMTQgYXQgODoxNCBB TSwgSm9uYXRoYW4gUm9zZW5iZXJnIDxqZHJvc2VuQGpkcm9zZW4ubmV0PG1haWx0bzpqZHJvc2Vu QGpkcm9zZW4ubmV0Pj4gd3JvdGU6DQpJJ20gaW4gZmF2b3Igb2YgdGFraW5nIGFub3RoZXIgcnVu IGF0IHRoaXMuDQoNClRoZSB3b3JraW5nIGdyb3VwIGhhcyByZXBlYXRlZGx5IHNhaWQgdGhhdCBh biBNVEkgY29kZWMgaXMgc29tZXRoaW5nIHdlIG5lZWQgdG8gcHJvZHVjZS4gQW5kIGl0cyBvbmUg b2YgdGhlIGlzc3VlcyBob2xkaW5nIHVwIHdpZGVyIGFkb3B0aW9uIG9mIHRoZSB0ZWNobm9sb2d5 IChub3QgdGhlIG9ubHkgb25lIGZvciBzdXJlKS4NCg0KQW5kIHRoaW5ncyBoYXZlIGNoYW5nZWQg c2luY2UgdGhlIGxhc3QgbWVldGluZywgYSB5ZWFyIGFnbyBub3cgKE5vdmVtYmVyIGluIFZhbmNv dXZlcikuIENpc2NvJ3Mgb3BlbjI2NCBwbHVnaW4gc2hpcHBlZCBhbmQgbm93IGp1c3QgcmVjZW50 bHkgaXMgaW50ZWdyYXRlZCBpbnRvIEZpcmVmb3guIGlPUzggc2hpcHBlZCB3aXRoIEFQSXMgZm9y IEgyNjQuIFRoZXJlIGFyZSBvdGhlciB0aGluZ3Mgd29ydGggbm90aW5nLiBXaWxsIHRoaXMgY2hh bmdlIHRoZSBtaW5kcyBvZiBldmVyeW9uZT8gU3VyZWx5IG5vdC4gV2lsbCBpdCBzd2F5IGVub3Vn aCBmb3IgdXMgdG8gYWNoaWV2ZSByb3VnaCBjb25zZW5zdXM/IE1heWJlLiBJTUhPIC0gd29ydGgg ZmluZGluZyBvdXQuDQoNCk9uIFNhdCwgT2N0IDE4LCAyMDE0IGF0IDU6MDggUE0sIEFsZXhhbmRy ZSBHT1VBSUxMQVJEIDxhZ291YWlsbGFyZEBnbWFpbC5jb208bWFpbHRvOmFnb3VhaWxsYXJkQGdt YWlsLmNvbT4+IHdyb3RlOg0KKzEgdG8gbm90IGhhdmluZyBNVEkgY29kZWMgZGlzY3Vzc2lvbiB1 bmxlc3Mgc29tZSBwcm9ncmVzcyBoYXMgYmVlbiBtYWRlIG9uIFZQOCBhdCBNUEVHLiBBbnkgbmV3 cyBvbiB0aGF0PyBJJ20gc2hhcmluZyBoYXJhbGQncyAgZmVlbGluZyB0aGF0IHRoZXJlIHdhcyBu byBjaGFuZ2Ugb24gdGhlIG1lbWJlcnMgcG9zaXRpb24uDQoNCk9uIEZyaSwgT2N0IDE3LCAyMDE0 IGF0IDk6MjIgUE0sIEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWls dG86aGFyYWxkQGFsdmVzdHJhbmQubm8+PiB3cm90ZToNCk9uIDEwLzE3LzIwMTQgMTI6MDIgQU0s IEJlcm5hcmQgQWJvYmEgd3JvdGU6DQpPbmUgdGhpbmcgd2UgY291bGQgZG8gaW5zdGVhZCBvZiB3 YXN0aW5nIHRpbWUgb24gTVRJIGlzIHRvIGFjdHVhbGx5IG1ha2UgcHJvZ3Jlc3Mgb24gU2VjdGlv bnMgNC4yIC0gNC40IG9mIGRyYWZ0LUlFVEYtUlRDV0VCLXZpZGVvLCBzbyB3ZSBjb3VsZCBhY3R1 YWxseSBpbnRlcm9wZXJhdGUgcmVnYXJkbGVzcyBvZiB0aGUgY29kZWMuDQoNClRoZSBiaWcgYXJn dW1lbnQgZm9yIGFuIE1USSBpcyBhY3R1YWxseSB0aGUgb25lIHN0YXRlZCBpbiAtb3ZlcnZpZXc6 IEl0IGd1YXJkcyBhZ2FpbnN0IGludGVyb3BlcmFiaWxpdHkgZmFpbHVyZS4NCg0KSSB3b3VsZCBs aWtlIHRvIGhhdmUgYW4gZWNvc3lzdGVtIHdoZXJlIG9uZSBjYW4gZmllbGQgYSBib3gsIGNvbm5l Y3QgaXQgdG8gZXZlcnl0aGluZyBlbHNlLCBhbmQgcnVuIHdlbGwgZm9yICpzb21lKiBsZXZlbCBv ZiAid2VsbCIgLSBhbmQgSSB3b3VsZCBwcmVmZXIgdGhhdCBlY29zeXN0ZW0gdG8gYmUgb25lIHdo ZXJlIGl0J3MgcG9zc2libGUgdG8gZmllbGQgdGhlIGJveCB3aXRob3V0IG1ha2luZyBwcmlvciBh cnJhbmdlbWVudHMgd2l0aCBhbnlvbmUgYWJvdXQgbGljZW5zZXMuDQoNClRoaXMgYXJndW1lbnQg aGFzbid0IGNoYW5nZWQgb25lIHdoaXQgc2luY2UgbGFzdCB0aW1lIHdlIGRpc2N1c3NlZCBpdC4g QW5kIEkgZG9uJ3Qgc2VlIG11Y2ggbW92ZW1lbnQgb24gdGhlIHNwZWNpZmljcyBvZiB0aGUgcHJv cG9zYWxzIGVpdGhlci4NCg0KV2UnbGwgaGF2ZSB0byBpbnRlcm9wZXJhdGUgd2VsbCB3aXRoIHRo ZSBjb2RlY3Mgd2UgZmllbGQuIFNvIHVzaW5nIHNvbWUgdGltZSB0byBkaXNjdXNzIGRyYWZ0LWll dGYtcnRjd2ViLXZpZGVvIHNlZW1zIHRvIG1ha2Ugc2Vuc2UuIChBbmQgNC4xIGlzbid0IGZpbmlz aGVkIGVpdGhlci4gVGhlcmUncyBvbmUgc2VudGVuY2UgdGhhdCBuZWVkcyB0byBiZSByZW1vdmVk LikNCg0KSSB3b3VsZG4ndCBzYXkgSSdkIGJlIGhhcHB5IHRvIG5vdCBkaXNjdXNzIHRoaXMgaW4g SG9ub2x1bHUuIEJ1dCBJJ2QgcHJlZmVyIHRvIHJlLWRpc2N1c3MgYmFzZWQgb24gdGhlIGtub3ds ZWRnZSB0aGF0IHNvbWUgc2lnbmlmaWNhbnQgcGxheWVycyBoYXZlIGFjdHVhbGx5IGNoYW5nZWQg dGhlaXIgbWluZHMuDQoNCkF0IHRoZSBtb21lbnQsIEkgZG9uJ3Qgc2VlIHNpZ25zIHRoYXQgYW55 IG9mIHRoZSBwb2xsIHJlc3BvbmRlbnRzIGhhdmUgc2FpZCAiSSBoYXZlIGNoYW5nZWQgbXkgbWlu ZCIuDQoNCkhhcmFsZA0KDQoNCk9uIE9jdCAxNiwgMjAxNCwgYXQgMjoyOCBQTSwgTWFydGluIFRo b21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21h aWwuY29tPj4gd3JvdGU6DQpPbiAxNiBPY3RvYmVyIDIwMTQgMTQ6MTcsIE1hdHRoZXcgS2F1Zm1h biA8bWF0dGhld0BtYXR0aGV3LmF0PG1haWx0bzptYXR0aGV3QG1hdHRoZXcuYXQ+PiB3cm90ZToN CkFuZCB0aGF0J3MgYmVjYXVzZSBzb21ldGhpbmcgc3Vic3RhbnRpdmUgaGFzIGNoYW5nZWQsIG9y IHNpbXBseSBiZWNhdXNlDQp3YXN0aW5nIHRoZSBXRyB0aW1lIG9uIHRoaXMgYWdhaW4gaXMgbW9y ZSBlbnRlcnRhaW5pbmcgdGhhbiBhY3R1YWxseQ0KZmluaXNoaW5nIGEgc3BlY2lmaWNhdGlvbiB0 aGF0IGNhbiBiZSBpbmRlcGVuZGVudGx5IGltcGxlbWVudGVkIGJ5IGFsbA0KYnJvd3NlciB2ZW5k b3JzPyAoQSBzcGVjaWZpY2F0aW9uIHRoYXQgd2UgYXJlIG5vd2hlcmUgbmVhciBoYXZpbmcsIGFz IGZhciBhcw0KSSBjYW4gdGVsbCkNClBlcnNvbmFsbHksIEkndmUgZm91bmQgdGhlIHJlcHJpZXZl IGZyb20gdGhpcyBmaWdodCByZWZyZXNoaW5nLiAgQW5kDQppdCB3b3VsZCBhcHBlYXIgdGhhdCB3 ZSd2ZSBtYWRlIHNvbWUgcmVhbCBwcm9ncmVzcyBhcyBhIHJlc3VsdC4gIEknZA0Kc3VnZ2VzdCB0 aGF0IGlmIHdlIGRvbid0IGhhdmUgbmV3IGluZm9ybWF0aW9uLCB3ZSBjb250aW51ZSB0byBzcGVu ZA0Kb3VyIHRpbWUgcHJvZHVjdGl2ZWx5LiAgSWYgd2UgY2FuJ3QgZmluZCB0b3BpY3MgdG8gb2Nj dXB5IG91ciBtZWV0aW5nDQphZ2VuZGEgdGltZSwgdGhlbiBtYXliZSB3ZSBjYW4gZnJlZSBhbiBh Z2VuZGEgc2xvdC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIg bWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0 DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQotLQ0KQWxleC4gR291YWlsbGFy ZCwgUGhELCBQaEQsIE1CQQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDVE8gLSBUZW1h c3lzIENvbW11bmljYXRpb25zLCBTJ3BvcmUgLyBNb3VudGFpbiBWaWV3DQpQcmVzaWRlbnQgLSBD b1NNbyBTb2Z0d2FyZSwgQ2FtYnJpZGdlLCBNQQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpzZy5saW5rZWRpbi5jb20vYWdvdWFpbGxhcmQ8aHR0cDovL3NnLmxpbmtlZGluLmNvbS9hZ291 YWlsbGFyZD4NCuKAog0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl Yg0KDQoNCg0KLS0NCkpvbmF0aGFuIFJvc2VuYmVyZywgUGguRC4NCmpkcm9zZW5AamRyb3Nlbi5u ZXQ8bWFpbHRvOmpkcm9zZW5AamRyb3Nlbi5uZXQ+DQpodHRwOi8vd3d3Lmpkcm9zZW4ubmV0DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIg bWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpydGN3ZWIgbWFpbGlu ZyBsaXN0DQoNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQoNCi0tDQoNClN1cnZl aWxsYW5jZSBpcyBwZXJ2YXNpdmUuIEdvIERhcmsuDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg0K --_000_E36D1A4AE0B6AA4091F1728D584A6AD240084E9Dfmsmsx118amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgQ29uc29sZSI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNCA1IDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OmluaGVyaXQ7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlm Ijt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RVZTIHN1cHBvcnRz IEFNUi1XQiBmdW5jdGlvbmFsaXR5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJl Zj0iaHR0cDovL3d3dy5ldHNpLm9yZy9kZWxpdmVyL2V0c2lfdHMvMTI2NDAwXzEyNjQ5OS8xMjY0 NDYvMTIuMDAuMDBfNjAvdHNfMTI2NDQ2djEyMDAwMHAucGRmIj5odHRwOi8vd3d3LmV0c2kub3Jn L2RlbGl2ZXIvZXRzaV90cy8xMjY0MDBfMTI2NDk5LzEyNjQ0Ni8xMi4wMC4wMF82MC90c18xMjY0 NDZ2MTIwMDAwcC5wZGY8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExlb24gR2V5c2VyIFttYWls dG86bGdleXNlckBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE9jdG9i ZXIgMjMsIDIwMTQgNzo1OCBBTTxicj4NCjxiPlRvOjwvYj4gQ2F2aWdpb2xpLCBDaHJpczxicj4N CjxiPkNjOjwvYj4gSGFyYWxkIEFsdmVzdHJhbmQ7IEJlcm5hcmQgQWJvYmE7IHJ0Y3dlYkBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUGxhbiBmb3IgTVRJIHZpZGVv IGNvZGVjPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBz ZWN0aW9uICc2IFVzZSBDYXNlcycgaXQgc2VlbXMgbGlrZSB0aGVyZSBpc24ndCBhbnkgdHJhbnNj b2RpbmcgcmVxdWlyZWQgYmV0d2VlbiBBTVItV0IgJmx0Oy0mZ3Q7IEVWUzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4gYW4gQU1SLVdCIGRlY29kZXIgZGVj b2RlIGFuIEVWUyBzdHJlYW0/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAyMyBPY3RvYmVyIDIwMTQgMTI6MTUsIENhdmlnaW9saSwgQ2hyaXMgJmx0Ozxh IGhyZWY9Im1haWx0bzpjaHJpcy5jYXZpZ2lvbGlAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ Y2hyaXMuY2F2aWdpb2xpQGludGVsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIEdTTUEgd2hpdGUgcGFwZXIgaGFzIGJlZW4gcHVibGlz aGVkLiZuYnNwOyBEb3dubG9hZCBhIGNvcHkgaGVyZTombmJzcDsNCjxhIGhyZWY9Imh0dHA6Ly93 d3cuZ3NtYS5jb20vbmV3c3Jvb20vd2VicnRjLWNvZGVjcy1kcmFmdC12MS0zLyIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cDovL3d3dy5nc21hLmNvbS9uZXdzcm9vbS93ZWJydGMtY29kZWNzLWRyYWZ0 LXYxLTMvPC9hPiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdGU6IFRyYW5zY29kaW5nIGNhbiBiZSBhdm9pZGVkIGJ5 IG5lZ290aWF0aW5nIG9wdGlvbmFsIGNvZGVjcyBhbmQgZmluZGluZyBhIG1hdGNoaW5nIHBhaXIu Jm5ic3A7IFRoZSBHU01BDQogd2hpdGUgcGFwZXIgZG9lc27igJl0IGZvY3VzIG9uIHRoYXQgY2Fz ZSwgYnV0IGluc3RlYWQgc3BlY2lmaWNhbGx5IGhpZ2hsaWdodHMgdGhlIHNjZW5hcmlvIHdoZXJl IGEgcHVyZSBXZWJSVEMgZW5kcG9pbnQgaXMgY29tbXVuaWNhdGluZyB3aXRoIGEgcHVyZSAzR1BQ IExURSBWb0xURS9WaUxURSBJTVMgZW5kcG9pbnQsIGFzc3VtaW5nIGVhY2ggZW5kcG9pbnQgT05M WSBoYXMgYWNjZXNzIHRvIHRoZSBNVEkgY29kZWNzIGluIGl0cyByZXNwZWN0aXZlDQogZG9tYWlu LiZuYnNwOyBJbiB0aGF0IGNhc2UsIHRoZSBuZXR3b3JrIGlzIHJlc3BvbnNpYmxlIHRvIHRyYW5z Y29kZSBiZXR3ZWVuIChPcHVzIG9yIEcuNzExLCAmbHQ7V2ViUlRDIE1USSB2aWRlbyBjb2RlYyBU QkQmZ3Q7KSBhbmQgKEFNUiBvciBBTVItV0IsIEguMjY0KS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5DYXZpZ2lvbGksIENocmlzPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRh eSwgT2N0b2JlciAxOSwgMjAxNCA2OjIwIFBNPGJyPg0KPGI+VG86PC9iPiBIYXJhbGQgQWx2ZXN0 cmFuZDsgQmVybmFyZCBBYm9iYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cnRj d2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUGxhbiBmb3IgTVRJIHZpZGVvIGNvZGVjPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGFy YWxkIHNhaWQ6Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPuKAnFdlIG1hZGUgdGhlIG1pc3Rha2Ugb2YgaGF2aW5nIGFuIE1USSBkaXNjdXNzaW9u IHByZXZpb3VzbHkgd2l0aCBub3QgZW5vdWdoIGRldGFpbHMgb24gdGhhdCBzdWJqZWN04oCm4oCd PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPldlIGRpZG7igJl0IGhhdmUgcXVhbnRpdGF0aXZlIGRhdGEgZWFybGllciBmb3IgYSBkYXRh LWRyaXZlbiBkZWNpc2lvbi4mbmJzcDsgRnV0dXJlIFdlYiDigJMgTFRFIGludGVyb3AgaXMgaW1w b3J0YW50LiZuYnNwOw0KIEEgZ3JvdXAgb2YgdXMgaW4gR1NNQSBoYXZlIGJlZW4gbG9va2luZyBh dCBXZWJSVEMgaW50ZXJvcCB3aXRoIExURSAod2hlcmUgM0dQUCAvIEdTTUEgZGVmaW5lZCBJTVMt YmFzZWQgdm9pY2UvdmlkZW8vbWVzc2FnaW5nKSwgc3BlY2lmaWNhbGx5IGxvb2tpbmcgYXQgdXNl ciBleHBlcmllbmNlIGltcGFjdCBvZiBsYXRlbmN5IGludHJvZHVjZWQgYnkgYWRkZWQgaW4tbmV0 d29yayB0cmFuc2NvZGluZy4mbmJzcDsgR1NNQSBoYXMgYXBwcm92ZWQgdGhlIHdoaXRlcGFwZXIN CiBhbmQgaXQgaXMgYmVpbmcgcHJlcGFyZWQgZm9yIHB1YmxpYyBkaXN0cmlidXRpb24uJm5ic3A7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+V2ViUlRDIOKAkyBMVEUgdHJhbnNjb2RpbmcgaXMgbm93IE1BTkRBVE9SWSBi ZWNhdXNlIG9mIOKAnFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJvY2Vzc2luZyBSZXF1aXJlbWVu dHPigJ0uDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi1hdWRpby0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTA1PC9hPiwgd2hlcmUgTVRJIGF1ZGlvIGNvZGVjcyBp biBXZWJSVEMgYW5kIGluIExURSBhcmUgZGlzc2ltaWxhci4mbmJzcDsgVGh1cywgUkVHQVJETEVT UyBvZiB0aGUgdmlkZW8gY29kZWNzLCB0aGVyZSBpcyBhbHJlYWR5IGENCiBzaWduaWZpY2FudCBk ZWdyYWRhdGlvbiBpbXBvc2VkIG9uIFdlYiDigJMgTFRFIGxpbmtzIGlmIG9ubHkgTVRJIGNvZGVj cyBhcmUgdXNlZC4mbmJzcDsgVGhlIG9ubHkgc3lzdGVtcyB0byBhdm9pZCB0aGlzIGFyZSB0aG9z ZSB3aGljaCBpbXBsZW1lbnQgT1BUSU9OQUwgYXVkaW8gY29kZWNzIHRvIGJlIHRyYW5zY29kZXIt ZnJlZSB3aXRoIExURS4mbmJzcDsgVGhlIHNhbWUgY2FuIGFwcGx5IGZvciB2aWRlbyBjb2RlY3Mu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGUgR1NNQSB3aGl0ZXBhcGVyIHJlZmVycyB0bzo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjEuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5RdWFudGl0YXRpdmUgdm9pY2Utb3Zlci1MVEUgKFZvTFRFKSBkZWxheSBsaW1pdHMg d2VyZSBhZ3JlZWQtdG8gYnkgM0dQUCBTQTQgaW4gQXVndXN0IDIwMTQuJm5ic3A7IFRvIHBhcmFw aHJhc2UsIHBlcmZvcm1hbmNlIG9iamVjdGl2ZXMgZm9yIG1heGltdW0gVm9MVEUgZGV2aWNlIGRl bGF5cyBpbiBlcnJvcg0KIGFuZCBqaXR0ZXIgZnJlZSBjb25kaXRpb25zIGFuZCBBTVIgc3BlZWNo IGNvZGVjIG9wZXJhdGlvbiwgdGhlIHN1bSBvZiB0aGUgVUUgZGVsYXlzIGluIHNlbmRpbmcgYW5k IHJlY2VpdmluZyBkaXJlY3Rpb25zIChUPHN1Yj5TPC9zdWI+ICYjNDM7IFQ8c3ViPlI8L3N1Yj4p IHNob3VsZCBiZSDiiaQgMTUwbXMuIElmIHRoaXMgcGVyZm9ybWFuY2Ugb2JqZWN0aXZlIGNhbm5v dCBiZSBtZXQsIHRoZSBzdW0gb2YgdGhlIFVFIGRlbGF5cyBpbiBzZW5kaW5nIGFuZA0KIHJlY2Vp dmluZyBkaXJlY3Rpb25zIChUPHN1Yj5TPC9zdWI+ICYjNDM7IFQ8c3ViPlI8L3N1Yj4pIHNoYWxs IGluIGFueSBjYXNlIGJlIOKJpCAxOTBtcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PUFVTIOKA kyBBTVIgdHJhbnNjb2RpbmcgYWRkcyBhbiBhZGRpdGlvbmFsIDIxMS41IG1zIGltcGxlbWVudGF0 aW9uLWFnbm9zdGljIChUPHN1Yj5TPC9zdWI+ICYjNDM7IFQ8c3ViPlI8L3N1Yj4pIGRlbGF5LCBp bmNsdWRpbmcgNDAgbXMgZm9yIGppdHRlciBidWZmZXIgYW5kIDQwIG1zIGZvciBkaXNjb250aW51 b3VzDQogcmVjZXB0aW9uIChEUlgpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+My48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRvIHB1dCB0aGVz ZSBudW1iZXJzIGluIHBlcnNwZWN0aXZlLCBpdCBpcyBpbiBnZW5lcmFsIGRlc2lyYWJsZSB0byBt aW5pbWl6ZSBVRSBkZWxheXMgdG8gZW5zdXJlIGxvdyBlbm91Z2ggZW5kLXRvLWVuZCBkZWxheXMg YW5kIGhlbmNlIGEgZ29vZCBjb252ZXJzYXRpb25hbCBleHBlcmllbmNlLiZuYnNwOyBJbmNyZWFz aW5nDQogZGVsYXkgY2F1c2VzIHBlb3BsZSB0byBkb3VibGUtdGFsayBtYWtpbmcgY29udmVyc2F0 aW9ucyBpbmNyZWFzaW5nbHkgZnJ1c3RyYXRpbmcuJm5ic3A7IEd1aWRhbmNlIHRvIHN0YXkgYmVs b3cgNDAwIG1zIG1heGltdW0gb25lLXdheSBkZWxheSBpcyBmb3VuZCBpbiBJVFUtVCBSZWNvbW1l bmRhdGlvbiBHLjExNCBhbmQgdGhlIGNvbXB1dGF0aW9uYWwgRS1tb2RlbCBpcyBpbiBJVFUtVCBS ZWNvbW1lbmRhdGlvbiBHLjEwNy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgYSBjb21wbGV4IHRvcGljIHdp dGggbWFueSBuZXR3b3JrIGZhY3RvcnMgaW4gcGxheS4mbmJzcDsgTFRFIG9wZXJhdG9ycyBpbiAz R1BQIHNlZWsgVUUgZGVsYXlzIChUPHN1Yj5TPC9zdWI+DQogJiM0MzsgVDxzdWI+Ujwvc3ViPikg YXJvdW5kIDE1MCBtcy4mbmJzcDsgQWRkaW5nIE9QVVMg4oCTIEFNUiB0cmFuc2NvZGluZyBpbiB0 aGUgbmV0d29yayBpbXBvc2VzIGFuIGFkZGl0aW9uYWwgMjExLjUgbXMgb24gdG9wIG9mIHRoYXQs IGp1c3QgZm9yIGF1ZGlvLiZuYnNwOyBPcHRpb25hbGx5IHVzaW5nIEFNUiBpbiBXZWJSVEMsIHRo b3NlIDIxMS41IG1zIGNhbiBiZSBlbGltaW5hdGVkLCBkZWxpdmVyaW5nIGEgc3VwZXJpb3IgZW5k LXVzZXIgZXhwZXJpZW5jZS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q09OQ0xVU0lPTjogJm5ic3A7cmVn YXJkbGVzcyBvZiBNVEkgY29kZWMgY2hvaWNlcyBpbiBXZWJSVEMsIHRvIHByb3ZpZGUgYSBnb29k IFdlYlJUQyDigJMgTFRFIGludGVyb3AgZXhwZXJpZW5jZSwNCiBlbWVyZ2luZyBXZWJSVEMgc3lz dGVtcyBtdXN0IGFjY29tbW9kYXRlIE1USSBjb2RlY3MgYWxyZWFkeSBkZXBsb3llZCBpbiB0aGUg TFRFIGRvbWFpbiBhbmQgaW4gbW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1zLCBuYW1lbHkgQU1SL0FN Ui1XQiBhbmQgSC4yNjQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QT1NJVElPTjombmJzcDsgVG8gYmUgY2xlYXIsIHNl dmVyYWwgSW50ZWwgU29DcyBsYXVuY2hlZCBhdCBNV0MgdGhpcyB5ZWFyIGZvciBzbWFydHBob25l cyBhbmQgdGFibGV0cyBzdXBwb3J0DQogYm90aCBWUDggYW5kIEguMjY0IGhhcmR3YXJlIGVuY29k ZSBhbmQgZGVjb2RlIOKAkyBzbyBJbnRlbCBpcyBjb2RlYy1uZXV0cmFsIGluIHRoaXMgTVRJIGRl YmF0ZS4mbmJzcDsgQWRkaXRpb25hbGx5LCBJbnRlbCBoYXMgaGlnaC1wZXJmb3JtYW5jZSBzb2x1 dGlvbnMgZm9yIHRyYW5zY29kaW5nLiZuYnNwOyBIb3dldmVyLCB3ZSB3aXNoIHRvIGluZm9ybSB0 aGUgaW5kdXN0cnksIHdpdGggcXVhbnRpdGF0aXZlIGRhdGEsIGFib3V0IGltcGFjdCB0byBlbmQt dXNlciBleHBlcmllbmNlDQogb2YgbWFuZGF0aW5nIHN1Y2ggdHJhbnNjb2Rpbmcgc28gSUVURiBj YW4gbWFrZSBhIGRhdGEtZHJpdmVuIGRlY2lzaW9uIG9uIHZpZGVvIGNvZGVjcyBhcyB3ZWxsIGFz IHJlZmxlY3Qgb24gdGhlIGltcGFjdCBvZiBhbHJlYWR5IGhhdmluZyBtYW5kYXRlZCB0cmFuc2Nv ZGluZyBvbiB0aGUgYXVkaW8gc2lkZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Q2hyaXMgQ2F2aWdpb2xpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbnRlbCBD b3JwLA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPlN5 c3RlbSBBcmNoaXRlY3R1cmUgYW5kIFBsYW5uaW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiwgVmlkZW8vTXVsdGltZWRpYSwgTW9iaWxlIGFuZCBDb21t dW5pY2F0aW9ucyBHcm91cCAoTUNHKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEg aHJlZj0idGVsOiUyQjElMjAlMjg0MTUlMjklMjAyNTQtNDU0NSIgdGFyZ2V0PSJfYmxhbmsiPiYj NDM7MSAoNDE1KSAyNTQtNDU0NTwvYT4gbW9iaWxlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48YSBocmVmPSJ0ZWw6JTJCMSUyMCUyODQwOCUyOSUyMDY1My04MzQ4IiB0YXJnZXQ9Il9i bGFuayI+JiM0MzsxICg0MDgpIDY1My04MzQ4PC9hPiBkZXNrPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48YSBocmVmPSJ0ZWw6JTJCMSUyMCUyODQwOCUyOSUyMDg4NC0yNDAwIiB0YXJn ZXQ9Il9ibGFuayI+JiM0MzsxICg0MDgpIDg4NC0yNDAwPC9hPiBmYXg8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmdyYXkiPlRoaXMgZS1tYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJp dmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykuJm5ic3A7DQogQW55IHJldmlldyBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgWzxhIGhyZWY9Im1h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlcm5hcmQgQWJv YmE8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBPY3RvYmVyIDE5LCAyMDE0IDI6MjkgUE08YnI+ DQo8Yj5Ubzo8L2I+IEhhcmFsZCBBbHZlc3RyYW5kPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gUGxhbiBmb3IgTVRJIHZpZGVvIGNv ZGVjPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IYXJhbGQgc2Fp ZDombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CZXJuYXJkLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YnI+DQpJIHRoaW5rIHRoaXMgaXMsIHRvIGEgbGFyZ2UgZGVncmVlLCBjb2RlYyBpbmRl cGVuZGVudC48YnI+DQo8YnI+DQpXZSBoYXZlIGRlbW9uc3RyYXRlZCBpbnRlcm9wZXJhYmlsaXR5 IG9uIFZQOCBiZXR3ZWVuIEZpcmVmb3ggYW5kIENocm9tZSwgYW5kIHVzYWdlIG9mIHZhcmlvdXMg bWVjaGFuaXNtcyBmb3IgY29uZ2VzdGlvbiBjb250cm9sIGFuZCByZXBhaXIgb2YgcGFja2V0IGxv c3MgYmVpbmcgYXBwbGllZCBpbiBsaXZlIHNlcnZpY2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlNvIGl0IGNhbid0IGJlIGFsbCBiYWQuLi4uLjwvc3Bhbj4mcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPltCQV0gJm5ic3A7SSBh Z3JlZSB0aGF0IHRoZSBsYWNrIG9mIGludGVyb3BlcmFiaWxpdHkgaXMgbGFyZ2VseSAmcXVvdDtj b2RlYyBpbmRlcGVuZGVudCZxdW90OzogJm5ic3A7IHRoYXQgaXMsIGltcGxlbWVudGF0aW9ucyBi YXNlZCBvbiBkaWZmZXJlbnQgbWVjaGFuaXNtcyBmb3IgY29uZ2VzdGlvbiBjb250cm9sLCByZXBh aXIsIGV0Yy4gd2lsbA0KIGV4aGliaXQgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcywgcmVnYXJk bGVzcyBvZiB0aGUgY29kZWMgY2hvc2VuLiAmbmJzcDsgVGhlIHJlYWwgdGVzdCBmb3IgUlRDV0VC IHdpbGwgYmUgdG8gbW92ZSBiZXlvbmQgJnF1b3Q7aW50ZXJvcGVyYWJpbGl0eSBvZiBpbXBsZW1l bnRhdGlvbnMgc2hhcmluZyBzb3VyY2UgY29kZSZxdW90OyAmbmJzcDt0byAmcXVvdDtpbnRlcm9w ZXJhYmlsaXR5IG9mIGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucywgYmFzZWQgb24gb3BlbiBz dGFuZGFyZHMmcXVvdDsuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBPY3QgMTksIDIwMTQgYXQgMToz OCBQTSwgSGFyYWxkIEFsdmVzdHJhbmQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0 cmFuZC5ubyIgdGFyZ2V0PSJfYmxhbmsiPmhhcmFsZEBhbHZlc3RyYW5kLm5vPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ T24gMTAvMTkvMjAxNCAwNTo0MyBQTSwgQmVybmFyZCBBYm9iYSB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDtBbmQgaXRz IG9uZSBvZiB0aGUgaXNzdWVzIGhvbGRpbmcgdXAgd2lkZXIgYWRvcHRpb24gb2YgdGhlIHRlY2hu b2xvZ3kmcXVvdDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPltCQV0gU3BlY2lmeWluZyBhbiBNVEkgZW5jb2Rlci9kZWNvZGVyIGlzIG5vdCBzdWZm aWNpZW50IGZvciBpbnRlcm9wZXJhYmlsaXR5LiZuYnNwOyBJdCBpcyBhbHNvIG5lY2Vzc2FyeSB0 byBzcGVjaWZ5IHRoZSB0cmFuc3BvcnQgaW4gZW5vdWdoIGRldGFpbCB0byBhbGxvdyBpbmRlcGVu ZGVudCBpbXBsZW1lbnRhdGlvbnMNCiB0aGF0IGludGVyb3BlcmF0ZSB3ZWxsIGVub3VnaCB0byBi ZSB1c2FibGUgaW4gYSB3aWRlIHZhcmlldHkgb2Ygc2NlbmFyaW9zLCBpbmNsdWRpbmcgd2lyZWxl c3MgbmV0d29ya3Mgd2hlcmUgbG9zcyBpcyBjb21tb25seSBleHBlcmllbmNlZC4mbmJzcDsNCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KQmVybmFyZCw8YnI+DQo8YnI+DQpJIHRoaW5rIHRoaXMgaXMsIHRv IGEgbGFyZ2UgZGVncmVlLCBjb2RlYyBpbmRlcGVuZGVudC48YnI+DQo8YnI+DQpXZSBoYXZlIGRl bW9uc3RyYXRlZCBpbnRlcm9wZXJhYmlsaXR5IG9uIFZQOCBiZXR3ZWVuIEZpcmVmb3ggYW5kIENo cm9tZSwgYW5kIHVzYWdlIG9mIHZhcmlvdXMgbWVjaGFuaXNtcyBmb3IgY29uZ2VzdGlvbiBjb250 cm9sIGFuZCByZXBhaXIgb2YgcGFja2V0IGxvc3MgYmVpbmcgYXBwbGllZCBpbiBsaXZlIHNlcnZp Y2VzLjxicj4NCjxicj4NClNvIGl0IGNhbid0IGJlIGFsbCBiYWQuLi4uLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBtYWRlIHRoZSBtaXN0 YWtlIG9mIGhhdmluZyBhbiBNVEkgZGlzY3Vzc2lvbiBwcmV2aW91c2x5IHdpdGggbm90IGVub3Vn aCBkZXRhaWxzIG9uIHRoYXQgc3ViamVjdCwgcGFydGljdWxhcmx5IHdpdGggcmVzcGVjdCB0byBI LjI2NC4gZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8gc2VjdGlvbnMgNC4yIC0gNC40DQogcmVtYWlu IHNrZXRjaHkgYXQgYmVzdC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TbyBpZiB3ZSBhcmUgdG8gaGF2ZSB0aGUgZGlzY3Vz c2lvbiBhZ2FpbiwgaXQgc2hvdWxkIG9jY3VyIGluIHRoZSBjb250ZXh0IG9mIGRldGFpbGVkIHNw ZWNpZmljYXRpb25zIGFuZCBpbnRlcm9wZXJhYmlsaXR5IHJlcG9ydHMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T24gU3VuLCBPY3QgMTksIDIwMTQgYXQgODoxNCBBTSwgSm9uYXRoYW4gUm9zZW5iZXJnICZs dDs8YSBocmVmPSJtYWlsdG86amRyb3NlbkBqZHJvc2VuLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmpk cm9zZW5AamRyb3Nlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBpbiBmYXZvciBvZiB0YWtpbmcgYW5vdGhlciBydW4g YXQgdGhpcy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoZSB3b3JraW5nIGdyb3VwIGhhcyByZXBlYXRlZGx5IHNhaWQgdGhhdCBhbiBNVEkgY29k ZWMgaXMgc29tZXRoaW5nIHdlIG5lZWQgdG8gcHJvZHVjZS4gQW5kIGl0cyBvbmUgb2YgdGhlIGlz c3VlcyBob2xkaW5nIHVwIHdpZGVyIGFkb3B0aW9uIG9mIHRoZSB0ZWNobm9sb2d5IChub3QgdGhl IG9ubHkgb25lDQogZm9yIHN1cmUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIHRoaW5ncyBoYXZlIGNoYW5nZWQgc2luY2UgdGhl IGxhc3QgbWVldGluZywgYSB5ZWFyIGFnbyBub3cgKE5vdmVtYmVyIGluIFZhbmNvdXZlcikuIENp c2NvJ3Mgb3BlbjI2NCBwbHVnaW4gc2hpcHBlZCBhbmQgbm93IGp1c3QgcmVjZW50bHkgaXMgaW50 ZWdyYXRlZCBpbnRvIEZpcmVmb3guIGlPUzggc2hpcHBlZA0KIHdpdGggQVBJcyBmb3IgSDI2NC4g VGhlcmUgYXJlIG90aGVyIHRoaW5ncyB3b3J0aCBub3RpbmcuIFdpbGwgdGhpcyBjaGFuZ2UgdGhl IG1pbmRzIG9mIGV2ZXJ5b25lPyBTdXJlbHkgbm90LiBXaWxsIGl0IHN3YXkgZW5vdWdoIGZvciB1 cyB0byBhY2hpZXZlIHJvdWdoIGNvbnNlbnN1cz8gTWF5YmUuIElNSE8gLSB3b3J0aCBmaW5kaW5n IG91dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU2F0LCBPY3QgMTgsIDIwMTQgYXQgNTowOCBQTSwgQWxl eGFuZHJlIEdPVUFJTExBUkQgJmx0OzxhIGhyZWY9Im1haWx0bzphZ291YWlsbGFyZEBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5hZ291YWlsbGFyZEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7MSB0byBu b3QgaGF2aW5nIE1USSBjb2RlYyBkaXNjdXNzaW9uIHVubGVzcyBzb21lIHByb2dyZXNzIGhhcyBi ZWVuIG1hZGUgb24gVlA4IGF0IE1QRUcuJm5ic3A7QW55IG5ld3Mgb24gdGhhdD8gSSdtIHNoYXJp bmcgaGFyYWxkJ3MgJm5ic3A7ZmVlbGluZyB0aGF0IHRoZXJlIHdhcyBubyBjaGFuZ2Ugb24gdGhl IG1lbWJlcnMNCiBwb3NpdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgT2N0IDE3LCAyMDE0IGF0 IDk6MjIgUE0sIEhhcmFsZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFs dmVzdHJhbmQubm8iIHRhcmdldD0iX2JsYW5rIj5oYXJhbGRAYWx2ZXN0cmFuZC5ubzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAxMC8xNy8y MDE0IDEyOjAyIEFNLCBCZXJuYXJkIEFib2JhIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbmUgdGhpbmcgd2UgY291bGQgZG8gaW5zdGVhZCBvZiB3YXN0aW5n IHRpbWUgb24gTVRJIGlzIHRvIGFjdHVhbGx5IG1ha2UgcHJvZ3Jlc3Mgb24gU2VjdGlvbnMgNC4y IC0gNC40IG9mIGRyYWZ0LUlFVEYtUlRDV0VCLXZpZGVvLCBzbyB3ZSBjb3VsZCBhY3R1YWxseSBp bnRlcm9wZXJhdGUgcmVnYXJkbGVzcw0KIG9mIHRoZSBjb2RlYy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KVGhlIGJpZyBhcmd1bWVudCBmb3IgYW4gTVRJIGlz IGFjdHVhbGx5IHRoZSBvbmUgc3RhdGVkIGluIC1vdmVydmlldzogSXQgZ3VhcmRzIGFnYWluc3Qg aW50ZXJvcGVyYWJpbGl0eSBmYWlsdXJlLjxicj4NCjxicj4NCkkgd291bGQgbGlrZSB0byBoYXZl IGFuIGVjb3N5c3RlbSB3aGVyZSBvbmUgY2FuIGZpZWxkIGEgYm94LCBjb25uZWN0IGl0IHRvIGV2 ZXJ5dGhpbmcgZWxzZSwgYW5kIHJ1biB3ZWxsIGZvciAqc29tZSogbGV2ZWwgb2YgJnF1b3Q7d2Vs bCZxdW90OyAtIGFuZCBJIHdvdWxkIHByZWZlciB0aGF0IGVjb3N5c3RlbSB0byBiZSBvbmUgd2hl cmUgaXQncyBwb3NzaWJsZSB0byBmaWVsZCB0aGUgYm94IHdpdGhvdXQgbWFraW5nIHByaW9yIGFy cmFuZ2VtZW50cyB3aXRoIGFueW9uZQ0KIGFib3V0IGxpY2Vuc2VzLjxicj4NCjxicj4NClRoaXMg YXJndW1lbnQgaGFzbid0IGNoYW5nZWQgb25lIHdoaXQgc2luY2UgbGFzdCB0aW1lIHdlIGRpc2N1 c3NlZCBpdC4gQW5kIEkgZG9uJ3Qgc2VlIG11Y2ggbW92ZW1lbnQgb24gdGhlIHNwZWNpZmljcyBv ZiB0aGUgcHJvcG9zYWxzIGVpdGhlci48YnI+DQo8YnI+DQpXZSdsbCBoYXZlIHRvIGludGVyb3Bl cmF0ZSB3ZWxsIHdpdGggdGhlIGNvZGVjcyB3ZSBmaWVsZC4gU28gdXNpbmcgc29tZSB0aW1lIHRv IGRpc2N1c3MgZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8gc2VlbXMgdG8gbWFrZSBzZW5zZS4gKEFu ZCA0LjEgaXNuJ3QgZmluaXNoZWQgZWl0aGVyLiBUaGVyZSdzIG9uZSBzZW50ZW5jZSB0aGF0IG5l ZWRzIHRvIGJlIHJlbW92ZWQuKTxicj4NCjxicj4NCkkgd291bGRuJ3Qgc2F5IEknZCBiZSBoYXBw eSB0byBub3QgZGlzY3VzcyB0aGlzIGluIEhvbm9sdWx1LiBCdXQgSSdkIHByZWZlciB0byByZS1k aXNjdXNzIGJhc2VkIG9uIHRoZSBrbm93bGVkZ2UgdGhhdCBzb21lIHNpZ25pZmljYW50IHBsYXll cnMgaGF2ZSBhY3R1YWxseSBjaGFuZ2VkIHRoZWlyIG1pbmRzLjxicj4NCjxicj4NCkF0IHRoZSBt b21lbnQsIEkgZG9uJ3Qgc2VlIHNpZ25zIHRoYXQgYW55IG9mIHRoZSBwb2xsIHJlc3BvbmRlbnRz IGhhdmUgc2FpZCAmcXVvdDtJIGhhdmUgY2hhbmdlZCBteSBtaW5kJnF1b3Q7LjxzcGFuIHN0eWxl PSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQpIYXJhbGQ8L3NwYW4+IDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ T24gT2N0IDE2LCAyMDE0LCBhdCAyOjI4IFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiAxNiBPY3RvYmVyIDIwMTQgMTQ6MTcsIE1hdHRoZXcgS2F1Zm1hbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1hdHRoZXdAbWF0dGhldy5hdCIgdGFyZ2V0PSJfYmxhbmsiPm1h dHRoZXdAbWF0dGhldy5hdDwvYT4mZ3Q7IHdyb3RlOjxicj4NCkFuZCB0aGF0J3MgYmVjYXVzZSBz b21ldGhpbmcgc3Vic3RhbnRpdmUgaGFzIGNoYW5nZWQsIG9yIHNpbXBseSBiZWNhdXNlPGJyPg0K d2FzdGluZyB0aGUgV0cgdGltZSBvbiB0aGlzIGFnYWluIGlzIG1vcmUgZW50ZXJ0YWluaW5nIHRo YW4gYWN0dWFsbHk8YnI+DQpmaW5pc2hpbmcgYSBzcGVjaWZpY2F0aW9uIHRoYXQgY2FuIGJlIGlu ZGVwZW5kZW50bHkgaW1wbGVtZW50ZWQgYnkgYWxsPGJyPg0KYnJvd3NlciB2ZW5kb3JzPyAoQSBz cGVjaWZpY2F0aW9uIHRoYXQgd2UgYXJlIG5vd2hlcmUgbmVhciBoYXZpbmcsIGFzIGZhciBhczxi cj4NCkkgY2FuIHRlbGwpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBl cnNvbmFsbHksIEkndmUgZm91bmQgdGhlIHJlcHJpZXZlIGZyb20gdGhpcyBmaWdodCByZWZyZXNo aW5nLiZuYnNwOyBBbmQ8YnI+DQppdCB3b3VsZCBhcHBlYXIgdGhhdCB3ZSd2ZSBtYWRlIHNvbWUg cmVhbCBwcm9ncmVzcyBhcyBhIHJlc3VsdC4mbmJzcDsgSSdkPGJyPg0Kc3VnZ2VzdCB0aGF0IGlm IHdlIGRvbid0IGhhdmUgbmV3IGluZm9ybWF0aW9uLCB3ZSBjb250aW51ZSB0byBzcGVuZDxicj4N Cm91ciB0aW1lIHByb2R1Y3RpdmVseS4mbmJzcDsgSWYgd2UgY2FuJ3QgZmluZCB0b3BpY3MgdG8g b2NjdXB5IG91ciBtZWV0aW5nPGJyPg0KYWdlbmRhIHRpbWUsIHRoZW4gbWF5YmUgd2UgY2FuIGZy ZWUgYW4gYWdlbmRhIHNsb3QuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dl YiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+QWxleC4g R291YWlsbGFyZCwgUGhELCBQaEQsIE1CQQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkNU TyAtIFRlbWFzeXMgQ29tbXVuaWNhdGlvbnMsIFMncG9yZSAvIE1vdW50YWluIFZpZXc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5QcmVzaWRlbnQgLSBDb1NNbyBTb2Z0d2FyZSwgQ2Ft YnJpZGdlLCBNQTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxhIGhyZWY9Imh0 dHA6Ly9zZy5saW5rZWRpbi5jb20vYWdvdWFpbGxhcmQiIHRhcmdldD0iX2JsYW5rIj5zZy5saW5r ZWRpbi5jb20vYWdvdWFpbGxhcmQ8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0OjE0LjRwdDt2ZXJ0aWNhbC1h bGlnbjpiYXNlbGluZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpTeW1ib2w7Y29sb3I6IzMzMzMzMyI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtjb2xvcjojMzMzMzMzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFt aWx5OiZxdW90O2luaGVyaXQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzMzMyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3 ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJy Pg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4tLQ0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Sm9uYXRoYW4gUm9zZW5iZXJnLCBQaC5ELjxicj4NCjxhIGhyZWY9 Im1haWx0bzpqZHJvc2VuQGpkcm9zZW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+amRyb3NlbkBqZHJv c2VuLm5ldDwvYT48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3Lmpkcm9zZW4ubmV0IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL3d3dy5qZHJvc2VuLm5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ydGN3ZWIgbWFpbGlu ZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPi0tIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+U3VydmVpbGxhbmNlIGlzIHBlcnZhc2l2ZS4gR28gRGFyay48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E36D1A4AE0B6AA4091F1728D584A6AD240084E9Dfmsmsx118amrcor_-- From nobody Sun Oct 26 16:33:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525991A1B13 for ; Sun, 26 Oct 2014 16:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqJHR7ZKn8l5 for ; Sun, 26 Oct 2014 16:33:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::631]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343281A1AE5 for ; Sun, 26 Oct 2014 16:33:39 -0700 (PDT) Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) with Microsoft SMTP Server (TLS) id 15.1.6.9; Sun, 26 Oct 2014 23:33:16 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.01.0006.000; Sun, 26 Oct 2014 23:33:15 +0000 From: "Wyss, Felix" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard Thread-Index: AQHP5CPxgL7/P4TbxUqqTVTHzTRXYJwplZVAgAA1HQCAAKtdYIAADzmAgAAmfQCAAFWsAIAAG4cggAEmdgCAADW+gIAAINaAgAAXDgCAAA+BgIAAIqQAgABN64CAAPELcIABF92AgATZ34CAAJFUwIABmHeAgAP3gnCAAAy6AIAAzlPggAAhVICAB+c40A== Date: Sun, 26 Oct 2014 23:33:15 +0000 Message-ID: <31789418b51e463dba22d83f7ea342f3@CY1PR0501MB1579.namprd05.prod.outlook.com> References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <543A5570.7060208@alvestrand.no> <543A9E11.2030605@alvestrand.no> <543ABE69.8030104@alvestrand.no> <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de> <71e2b21516cb496eb4d1ad2b26e53a29@CY1PR0501MB1579.namprd05.prod.outlook.com> <543CD1CD.3000001@alvestrand.no> <5440E38F.9070809@jesup.org> <5442B41D.6040307@jesup.org> <514191b6e7 764d30be7ea17d324d8739@CY1PR0501MB1579.namprd05.prod.outlook.com> <46b327b5be5a4fbcb508f664aea6cba2@CY1PR0501MB1579.namprd05.prod.outlook.com> <5446DBB1.7090801@jesup.org> In-Reply-To: <5446DBB1.7090801@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.147.12.61] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1578; inin-custom-wld: WL-D x-forefront-prvs: 0376ECF4DD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(199003)(189002)(164054003)(106356001)(66066001)(80022003)(46102003)(106116001)(99286002)(105586002)(4396001)(95666004)(99396003)(74316001)(40100003)(122556002)(107886001)(20776003)(107046002)(64706001)(108616004)(85306004)(93886004)(76482002)(87936001)(85852003)(77096002)(92566001)(76176999)(86362001)(101416001)(120916001)(33646002)(2501002)(76576001)(50986999)(54356999)(21056001)(31966008)(230783001)(97736003)(2656002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1578; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: inin.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O1mER6IB5WAVAZwRCPTgDMNYO6Q Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 23:33:41 -0000 > I had a suspicion that this was the intended use-case - and it's a real u= se-case > for certain applications/industries. >=20 > So, for those applications (remembering that webrtc applications are not > random external devices, but basically code linked to the usage) just eit= her > use pre-defined or external negotiation for channel assignments, or > implement *in the application* allocation-choosing strategy. Such as: >=20 > middlebox: offer to A and B (actpass) > A: accept (active) > B: accept (active) > ok, now both are on the same "evenness" > both statically open (pre-defined) channel 0 always Both send a random > token value The side with the lower random value is even, and the other i= s > odd All channel allocations are preceeded by message on channel 0 that > amounts to an "I'm opening channel N with these params" that takes the > place of DCEP Encapsulate this behavior in some simple functions that tak= e > the place of the default createDataChannel()/etc >=20 > There are other solutions of course for glare resolution. If you want, i= f the > two sides chose the opposite evenness, you just leave createDataChannel > alone. There are a LOT of ways to deal with this at the application leve= l, since > the application "should" know it's talking to (or may be talking to) a > middlebox that will decrypt/forward things. My discomfort and objection is with using the DTLS roles--even if it's just= as default. Why can't we either leave it up to the application to allocat= e the IDs, suggest some "best practice" approaches, or codify one as the pr= eferred? I don't feel strongly either way. All I care about here is that = we don't use the DTLS role for anything related to DCEP. DTLS should just = be an opaque transport for the endpoints' SCTP packets. If we leave the DT= LS role as default in the RFC, middleboxes have to worry about it because i= t's part of the standard. It doesn't matter that the application _can_ use= other means. If it's in the RFC, it is part of an implied interface cont= ract and 3rd party developers and system integrators will expect it to be s= upported and work as specified. =20 Thanks, --Felix From nobody Mon Oct 27 05:11:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BA41A923B for ; Mon, 27 Oct 2014 05:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYKtMpQuU1X3 for ; Mon, 27 Oct 2014 05:10:47 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EFAF1A9232 for ; Mon, 27 Oct 2014 05:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14992; q=dns/txt; s=iport; t=1414411816; x=1415621416; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CfieLu/xeP6ZI5zt3nD7/VkKQS7QYIqy6Q1CfsiU0l8=; b=L2n0OXN3Y73EgISl7vgyQqHS8q4RKbeEwMqlJ21Z2Keg52BpS0Dai0lT 6OoxVtNViF3P/difkcpSFvzGkbH9rEAWmjq9MmtrU0bQ42Nm0CG3XoweL 7x7PyroL1+Om9mlV9potxcZvqwdyUSkO+GT7V4+8OzGLH6CfV0FexnrB1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFAPY0TlStJA2F/2dsb2JhbABcgkhGVFgEzTEBCYZ5VAKBFhYBcguEAgEBAQQBAQEqQQsMBAIBCBEDAQEBCx0HJwsUCQgCBA4FCIg5DclXAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BXIA0EBgEGgyeBHgWFFQKMcIRIgkOGPJRBg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos; i="5.04,795,1406592000"; d="scan'208,217"; a="90640612" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 27 Oct 2014 12:10:15 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9RCAFgp029226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 12:10:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 07:10:15 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft-ietf-rtcweb-transports-07.txt Thread-Index: AQHP8d5ZlbbCz7ldKkqyzNNpC1BdnZxD2P0g Date: Mon, 27 Oct 2014 12:10:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2834FE75@xmb-rcd-x10.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D4C18C0@ESESSMB209.ericsson.se> <27059BBA-4094-469F-BE8B-156C0692A02F@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.221] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2834FE75xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IGWaA4I4y-RyhSzCOFBlGz0upSc Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 12:10:55 -0000 --_000_913383AAA69FF945B8F946018B75898A2834FE75xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In order to avoid the confusion, we recently published http://tools.ietf.or= g/html/draft-patil-tram-turn-serv-selection-00 which describes TURN selecti= on criteria, as guidelines, that can be used by a client to perform an info= rmed TURN server selection decision when a client discovers multiple TURN s= ervers. -Tiru From: Justin Uberti > Date: Friday, October 24, 2014 1:01 AM To: "Olle E. Johansson" > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt Generally, I think there is a fair amount of confusion about how these vari= ous types of TURN servers are going to work. The RETURN draft takes a first= stab at defining the interactions here, and ideally it can be adopted as a= WG draft and referred to by -transports. On Thu, Oct 23, 2014 at 5:26 AM, Olle E. Johansson > wrote: On 22 Oct 2014, at 16:57, Benjamin Schwartz > wrote: FYI, the purpose of the RETURN draft (https://tools.ietf.org/html/draft-sch= wartz-rtcweb-return-03) is to try to specify the precise interaction and pr= ecedence when both the browser and the application provide TURN servers. (= It's not as simple as "one or the other".) I haven't considered the issues related to browser-provided STUN servers, t= hough. Cool! I'll take a look at that. Maybe Haralds draft need to refer to that. /O On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg > wrote: Hi, The advantage of an application configuration is that it can be dynamically= provided/updated, based on location based etc - assuming the webpage provi= der has knowledge about STUN/TURN servers, of course. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. Johansson Sent: 22 October 2014 17:44 To: rtcweb@ietf.org Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt Section 3.4 " WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application." Should we mention which takes precedence? If configured in the browser, sta= rt with that server. If not use the one provided by the application. Maybe we should clarify that turn DNS discovery MUST be used to provide fai= lover and load balancing. /O _______________________________________________ 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 --_000_913383AAA69FF945B8F946018B75898A2834FE75xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In order to avoid the con= fusion, we recently published http://tools.ietf.org/html/draft-patil-tram-t= urn-serv-selection-00 which describes TURN selection criteria, as guidelines, that can be used by a client to perform an informed TURN se= rver selection decision when a client discovers multiple TURN servers. = ;

 <= /p>

-Tiru

 <= /p>

From: Justin Uberti <juberti@google.com>
Date: Friday, October 24, 2014 1:01 AM
To: "Olle E. Johansson" <oej@edvina.net>
Cc: "rtcweb@ietf.org&quo= t; <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt=

 

Generally, I think there is= a fair amount of confusion about how these various types of TURN servers a= re going to work. The RETURN draft takes a first stab at defining the interactions here, and ideally it can be adopted as a WG draf= t and referred to by -transports.

 

On Thu, Oct 23, 2014 at 5:2= 6 AM, Olle E. Johansson <oej@edvina.net> wrote:

 

On 22 Oct 2014, at 16:57, B= enjamin Schwartz <bemasc@webrtc.org> wrote:



FYI, the purpose of the RET= URN draft (https://tools.ietf.org/html/draft-schwartz-rtcweb= -return-03) is to try to specify the precise interaction and precedence when both the = browser and the application provide TURN servers.  (It's not as simple= as "one or the other".)

 

I haven't considered the is= sues related to browser-provided STUN servers, though.

Cool! I'll take a look at t= hat. Maybe Haralds draft need to refer to that.

 <= /p>

/O=



 

On Wed, Oct 22, 2014 at 10:= 51 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

The advantage of an application configuration is that it can be dynamically= provided/updated, based on location based etc - assuming the webpage provi= der has knowledge about STUN/TURN servers, of course.

Regards,

Christer


-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. Johansson
Sent: 22 October 2014 17:44
To: rtcweb@ietf.org
Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt

Section 3.4

" WebRTC browsers MUST support configuration of STUN and TURN servers,=
   both from browser configuration and from an application."=


Should we mention which takes precedence? If configured in the browser, sta= rt with that server.
If not use the one provided by the application.

Maybe we should clarify that turn DNS discovery MUST be used to provide fai= lover and load balancing.

/O
_______________________________________________
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

 

--_000_913383AAA69FF945B8F946018B75898A2834FE75xmbrcdx10ciscoc_-- From nobody Mon Oct 27 06:13:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A66D1A8028 for ; Mon, 27 Oct 2014 06:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSsGgvO9uOep for ; Mon, 27 Oct 2014 06:12:57 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C321AC409 for ; Mon, 27 Oct 2014 06:12:51 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-93-544e44d1d3da Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3E.E7.04231.1D44E445; Mon, 27 Oct 2014 14:12:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 14:12:48 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3w== Date: Mon, 27 Oct 2014 13:12:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4CCEEFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje5FF78Qg4sN6hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+K8DpaC1zIVP67/YG5g3CHZxcjJISFgIvHvyCdWCFtM4sK9 9WxdjFwcQgJHGCVWLJjBCuEsYZRYMK2HqYuRg4NNwEKi+582SIOIgLrE5YcX2EFsYQFjiZPP /7BBxC0kVv+5yAhh60ksPLCdCcRmEVCV+LqznwXE5hXwlbgzrQuslxFo8fdTa8BqmAXEJW49 mc8EcZCAxJI955khbFGJl4//QR2qKNH+tIER5BxmgXyJM4/sIUYKSpyc+YRlAqPQLCSTZiFU zUJSBVGiI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tL LdnECIyHg1t+6+5gXP3a8RCjAAejEg/vhxrfECHWxLLiytxDjNIcLErivIvOzQsWEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwCjYddymQmKv3UHrDN/pGcL3ogVzXz78o7NMiaVyZrLgq7W/ X5ycmlp8pfxhysEOr8J5wSt5bgfalVrr/2CccDat1E5wff6nVTduVxjNVuQTYSgJj/vvJ31l 65fYRR851y+++fd/Q22WSZdJgv7HL6eXOE03Zwy2kk84fmHH1ncM/WnRs1maOJVYijMSDbWY i4oTAXEBjbRoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GPVMarMAhTGxDQnqgYVwtxEzuJs Subject: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 13:12:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4CCEEFESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Within the CLUE WG, we had a discussion regarding the following statement i= n section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: "The support for message interleaving as defined in [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." First, it is a little unclear what "the support SHOULD be used" means. Second, does it mean that any data channel protocol (e.g CLUE) SHOULD use i= nterleaving, even if the characteristics of the protocol wouldn't require i= t? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4CCEEFESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Within the CLUE WG, we had a discussion regarding th= e following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.t= xt:

 

“The support for = message interleaving as defined in

         &nb= sp;      [I-D.ietf-tsvwg-sctp-ndata] SHOULD be use= d.”

 

First, it is a little unclear what “the suppor= t SHOULD be used” means.

 

Second, does it mean that any data channel protocol = (e.g CLUE) SHOULD use interleaving, even if the characteristics of the prot= ocol wouldn’t require it?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D4CCEEFESESSMB209erics_-- From nobody Mon Oct 27 07:11:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7249C1ACD59 for ; Mon, 27 Oct 2014 07:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTiN6IjTtC65 for ; Mon, 27 Oct 2014 07:10:55 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC3D1ACD67 for ; Mon, 27 Oct 2014 07:10:34 -0700 (PDT) Received: from [192.168.1.200] (p508F0FB4.dip0.t-ipconnect.de [80.143.15.180]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6AE611C105103; Mon, 27 Oct 2014 15:10:31 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> Date: Mon, 27 Oct 2014 15:10:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ET-9dFbH5Tyc5tIk7WUUj3lx7AY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 14:11:01 -0000 On 27 Oct 2014, at 14:12, Christer Holmberg = wrote: > Hi, > =20 > Within the CLUE WG, we had a discussion regarding the following = statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: > =20 > =93The support for message interleaving as defined in > [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used.=94 > =20 > First, it is a little unclear what =93the support SHOULD be used=94 = means. My understanding is that SCTP implementations supporting the extension = will use it. This is negotiated during the setup of the SCTP association. Whether messages are interleaved or not depends on the stream scheduler. = This is a sender side only decision. The receiver has to deal with it. It is not a MUST, since there are implementations now in use which don't = support the extension. Best regards Michael > =20 > Second, does it mean that any data channel protocol (e.g CLUE) SHOULD = use interleaving, even if the characteristics of the protocol wouldn=92t = require it? > =20 > Regards, > =20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Oct 27 07:20:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430431A8757 for ; Mon, 27 Oct 2014 07:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhMz0vTGkpO5 for ; Mon, 27 Oct 2014 07:19:23 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597AA1A874A for ; Mon, 27 Oct 2014 07:19:14 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-8a-544e5460cad2 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6C.77.04081.0645E445; Mon, 27 Oct 2014 15:19:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 15:19:12 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3////5gA///tr8A= Date: Mon, 27 Oct 2014 14:19:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW5CiF+Iwe+byhYXm5YwWqz9187u wOSxZMlPJo8NLTuYApiiuGxSUnMyy1KL9O0SuDLabn1kLnjLVbFt72/WBsZTHF2MnBwSAiYS +//sYoawxSQu3FvP1sXIxSEkcIRR4nvje0aQhJDAEkaJyYstuhg5ONgELCS6/2mDhEUETCUO Lp/HAmIzC6hL3Fl8jh3EFhZwkDi7cxI7RI2jRNvb80wQtpXE+wd7wUayCKhKLPzWAraXV8BX 4vv/S1B7Oxgl7jxcCtbMKeAq8f3XTrAiRqDjvp9awwSxTFzi1pP5TBBHC0gs2XMe6gFRiZeP /7FC2IoS7U8bGCHqdSQW7P7EBmFrSyxb+BpqsaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiy ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwfg5u+W2wg/Hlc8dDjAIcjEo8vB9qfEOEWBPL iitzDzFKc7AoifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjwUM+/cLbL4SeyPg6 W0goVdf8T9fN+HasP25urPLBCt6lB6+eN9X/YbHM9eTs/r/ON1fOfL7qzNIiaca5MUd/z/o2 JcV/1e4Y05uLI39PYvp0osLeUd5HMTn94pI3piqbMhc5FuwSMsvjaTOS9d1oErekrDb6/GaG i4/S3unpxs3euKHkuH6xEktxRqKhFnNRcSIATGvdWoACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UEGr2b8xA9ghk2olhr_pTro2rl4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 14:19:26 -0000 Hi, >> Within the CLUE WG, we had a discussion regarding the following statemen= t in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >> =20 >> "The support for message interleaving as defined in >> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >> =20 >> First, it is a little unclear what "the support SHOULD be used" means. > > My understanding is that SCTP implementations supporting the extension wi= ll use it. > This is negotiated during the setup of the SCTP association. If it's done on SCTP level, why do we need to talk about it in the data cha= nnel draft?=20 Is there a reason why it is important to use it for data channels? If so, d= oes it apply to data channels in general?=20 Regards, Christer Whether messages are interleaved or not depends on the stream scheduler. Th= is is a sender side only decision. The receiver has to deal with it. It is not a MUST, since there are implementations now in use which don't su= pport the extension. Best regards Michael > =20 > Second, does it mean that any data channel protocol (e.g CLUE) SHOULD use= interleaving, even if the characteristics of the protocol wouldn't require= it? > =20 > Regards, > =20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Oct 27 09:13:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCF11A002C; Mon, 27 Oct 2014 09:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZrj6yL6syIo; Mon, 27 Oct 2014 09:13:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DACE1A0039; Mon, 27 Oct 2014 09:13:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027161307.1245.53863.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 09:13:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZpKcfwmT6nkdALcL1sXY64--pyE Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 16:13:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-08.txt Pages : 9 Date : 2014-10-27 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 09:36:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0853E1A00C2 for ; Mon, 27 Oct 2014 09:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBJ_jOsc5opy for ; Mon, 27 Oct 2014 09:36:34 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3AE1A00FA for ; Mon, 27 Oct 2014 09:36:34 -0700 (PDT) Received: from [130.209.247.112] (port=60069 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XinHT-00086i-OD; Mon, 27 Oct 2014 16:36:32 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_0412D1B8-350B-4622-BEB7-F757E7724EBA" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <5446ACD8.1010004@gmail.com> Date: Mon, 27 Oct 2014 16:36:26 +0000 Message-Id: References: <5446ACD8.1010004@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5HDPYDS_sNKhBjzEhsldRhh6xEs Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 16:36:39 -0000 --Apple-Mail=_0412D1B8-350B-4622-BEB7-F757E7724EBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 21 Oct 2014, at 19:58, Sergio Garcia Murillo = wrote: > Not sure if it is done on pourpose, but according to the RTP usage = draft, it may seem that full RFC 4588 is mandated at the recevier side: >=20 > Receivers are REQUIRED to implement support for RTP retransmission > packets [RFC4588]. >=20 > That would include both modes, session and ssrc multiplexing. Given = the extensive usage of bundle and current implementations, session = multiplexing support doesn't make much sense. >=20 > Should we drop it, and state that only ssrc-multiplexing shall be = supported at the receiving end? I don=92t see any advantage to doing so, given that support for = non-BUNDLE sessions is REQUIRED. You need to implement the signalling = needed for session-multiplexing of retransmission packet anyway, so = disallowing it buys you nothing. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_0412D1B8-350B-4622-BEB7-F757E7724EBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

On 21 Oct 2014, at 19:58, = Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
Not sure if it is done on pourpose, = but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement =
support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving = end?

I don=92t see any advantage to = doing so, given that support for non-BUNDLE sessions is REQUIRED. You = need to implement the signalling needed for session-multiplexing of = retransmission packet anyway, so disallowing it buys you = nothing.

-- 
Colin Perkins

<= /div>


= --Apple-Mail=_0412D1B8-350B-4622-BEB7-F757E7724EBA-- From nobody Mon Oct 27 09:41:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9398C1A1A4B for ; Mon, 27 Oct 2014 09:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAqx3senVGBo for ; Mon, 27 Oct 2014 09:41:20 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51161A1A27 for ; Mon, 27 Oct 2014 09:40:32 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so1738942wgg.28 for ; Mon, 27 Oct 2014 09:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=8kIeqK2sW4EZn20IzOlqhvSdvn4h6Vp7RpoAj3qUwG4=; b=V/wGFFaf8g/GjNBg/gYZ869R2zUnRRbxDmWZnv9TAQpGbGPLgINJp2JVIN9Nq9dNth PhWiLuilRul6l8TZHQzTC2yyVR7KTa9YdTQy8MbupypsxHm1SRDfT1Nskv+MrbMR/W3G KsDRTZDFaslF1sqs2/xhwq431MCUjEcPIiMrq8PMiBXoe6pdTPC1KiJ0vOSoZkk5wKzG Yf2dFwpAC9B8zGSdW+o+XO485E9C5AvKLg7GtNUq4rllWaGNDApw3zA/JTxOkUAB893x PIU7kExRZHoQQmY5EQWS4zr8CrfQGL+ZG5s1g7MH/AzfLMqT3v+NSQ16dAOA8FfWlWN6 GKXw== X-Received: by 10.180.205.171 with SMTP id lh11mr22154943wic.66.1414428030991; Mon, 27 Oct 2014 09:40:30 -0700 (PDT) Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id c15sm10591554wib.3.2014.10.27.09.40.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 09:40:30 -0700 (PDT) Message-ID: <544E7586.4080703@gmail.com> Date: Mon, 27 Oct 2014 17:40:38 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Colin Perkins References: <5446ACD8.1010004@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060408080202040307060508" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OczHwWKobVpZ4_knwEmtWsPSehU Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 16:41:24 -0000 This is a multi-part message in MIME format. --------------060408080202040307060508 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 27/10/2014 17:36, Colin Perkins wrote: > Hi, > > On 21 Oct 2014, at 19:58, Sergio Garcia Murillo > > wrote: >> Not sure if it is done on pourpose, but according to the RTP usage >> draft, it may seem that full RFC 4588 is mandated at the recevier side: >> >> Receivers are REQUIRED to implement support for RTP retransmission >> packets [RFC4588 ]. >> >> That would include both modes, session and ssrc multiplexing. Given >> the extensive usage of bundle and current implementations, session >> multiplexing support doesn't make much sense. >> >> Should we drop it, and state that only ssrc-multiplexing shall be >> supported at the receiving end? > > I don’t see any advantage to doing so, given that support for > non-BUNDLE sessions is REQUIRED. You need to implement the signalling > needed for session-multiplexing of retransmission packet anyway, so > disallowing it buys you nothing. > You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions. Best regards Sergio --------------060408080202040307060508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 27/10/2014 17:36, Colin Perkins wrote:
Hi,

On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don’t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.


You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

Best regards
Sergio
--------------060408080202040307060508-- From nobody Mon Oct 27 09:42:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D096A1A19F3 for ; Mon, 27 Oct 2014 09:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc2_9ATJ41Os for ; Mon, 27 Oct 2014 09:42:07 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBA21A1A25 for ; Mon, 27 Oct 2014 09:41:14 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id z12so2644356lbi.11 for ; Mon, 27 Oct 2014 09:41:12 -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=TnHZ9BBTqd0V3da2CS2j7Mg4hVN4wO0mmRp12WZ+Ugw=; b=aD80JnjKe3bRCv7phpNnHlLND6g2hhMxLhKgtctYdxLy5LVJYX9PZ/Zn/fCAm0uP8T k9+VMAbnxLFrhhwRNISUcCrNDQ2p9l05cc1Tv/ji3jaHQbUo/xBLScNTj6FWxJzsYPHL fAq/vSoRe/nkJC2AoALxcfLJYe41aYVya++gdg6YdblENk5ZOpAvCv9RaAbldwIsHxh5 CIrzX4tU6K3umUENYC9JBHpO6zQwM+gxiybQcVt4pARMJt/0toPdZIgD0g9bxi8C6++d hUoFk9q8Nb08FWo/c9NwUujnjrMWkGMXL3Wbe8ImAIZVgEcT2GFzVEs7rWyK3tgwxFe8 bUww== MIME-Version: 1.0 X-Received: by 10.152.116.102 with SMTP id jv6mr25069639lab.40.1414428072801; Mon, 27 Oct 2014 09:41:12 -0700 (PDT) Received: by 10.25.77.73 with HTTP; Mon, 27 Oct 2014 09:41:12 -0700 (PDT) Date: Mon, 27 Oct 2014 17:41:12 +0100 Message-ID: From: Victor Pascual Avila To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oMVESoFpoohEKjyy7kegKYPXuvA Subject: [rtcweb] In case you missed it... MSFT and WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 16:42:09 -0000 http://blogs.skype.com/2014/10/27/bringing-interoperable-real-time-communications-to-the-web/ https://status.modern.ie/webrtcwebrtcv10api?term=webrtc -Victor From nobody Mon Oct 27 09:46:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE1F1A1A38 for ; Mon, 27 Oct 2014 09:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dwP_pGFTpSv for ; Mon, 27 Oct 2014 09:46:05 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218311A1A90 for ; Mon, 27 Oct 2014 09:45:13 -0700 (PDT) Received: from [130.209.247.112] (port=60102 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XinPq-0000Wk-1R; Mon, 27 Oct 2014 16:45:10 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_0EE27D34-EFAB-41C1-9854-73CFFF84BDA8" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <544E7586.4080703@gmail.com> Date: Mon, 27 Oct 2014 16:45:01 +0000 Message-Id: <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/q3Cgtvg7L8aRzfJrxfTmPC1nUeo Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 16:46:07 -0000 --Apple-Mail=_0EE27D34-EFAB-41C1-9854-73CFFF84BDA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 27 Oct 2014, at 16:40, Sergio Garcia Murillo = wrote: > On 27/10/2014 17:36, Colin Perkins wrote: >> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo = wrote: >>> Not sure if it is done on pourpose, but according to the RTP usage = draft, it may seem that full RFC 4588 is mandated at the recevier side: >>>=20 >>> Receivers are REQUIRED to implement support for RTP = retransmission >>> packets [RFC4588]. >>>=20 >>> That would include both modes, session and ssrc multiplexing. Given = the extensive usage of bundle and current implementations, session = multiplexing support doesn't make much sense. >>>=20 >>> Should we drop it, and state that only ssrc-multiplexing shall be = supported at the receiving end? >>=20 >> I don=92t see any advantage to doing so, given that support for = non-BUNDLE sessions is REQUIRED. You need to implement the signalling = needed for session-multiplexing of retransmission packet anyway, so = disallowing it buys you nothing. >=20 > You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what = I don't see is how to do session multiplexing with BUNDLE sessions.=20 You can=92t do session multiplexing for BUNDLE sessions; by definition = they use SSRC multiplexing. You could do non-BUNDLE sessions, with = retransmission sent on a separate RTP session though. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_0EE27D34-EFAB-41C1-9854-73CFFF84BDA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 27 = Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
=20 =20
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia = Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
Not sure if it is = done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier = side:

    Receivers are =
REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don=92t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=92t do = session multiplexing for BUNDLE sessions; by definition they use SSRC = multiplexing. You could do non-BUNDLE sessions, with retransmission sent = on a separate RTP session though.

-- 
Colin Perkins

<= /div>


= --Apple-Mail=_0EE27D34-EFAB-41C1-9854-73CFFF84BDA8-- From nobody Mon Oct 27 09:51:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BB81A00D7 for ; Mon, 27 Oct 2014 09:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxyBgqwm6Ejc for ; Mon, 27 Oct 2014 09:51:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6941A1AC7 for ; Mon, 27 Oct 2014 09:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2614; q=dns/txt; s=iport; t=1414428646; x=1415638246; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Fd1hr/b+9eRZCajUsySYVvGPSimw5o9TWmc9kWCVP7c=; b=IVfVH7c7mNI69efrMpTFKWBBr2URR6sJ6zhxTImhihZCrwe5PsIT5jg3 +dshFy6mSSfTjBGqLBive6HA11gJqrzWVZMlTsDYf6z4ZE1Y5mNIB9Mh/ z+srxtXlnZY6JrknNScI4ZL77/s7Fepn9CVreD5HHUoX1IAz5X3gUUM/c c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAJZ2TlStJA2D/2dsb2JhbABcgw5UUwUEzTEMhndUAoEdFgFyC4QCAQEBBAEBATc0FwQCAQgRAwECHxAnCx0IAgQTCYg4CAXLRQEBAQEBAQQBAQEBAQEBG5A3AQEcNQUGhEUFkgeESIcSgTE8gw2RNIN4bAGBDjmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,796,1406592000"; d="scan'208";a="367075627" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP; 27 Oct 2014 16:50:45 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9RGoj4J017473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Oct 2014 16:50:45 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.26]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 11:50:45 -0500 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt Thread-Index: AQHP8gYm65ffmJyZKEOlfZBtM6F5JA== Date: Mon, 27 Oct 2014 16:50:44 +0000 Message-ID: References: <20141027161307.1245.53863.idtracker@ietfa.amsl.com> In-Reply-To: <20141027161307.1245.53863.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.50.201] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UddRKcDH1UKBAbiBp6Vw4jt8M7c Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 16:51:48 -0000 This revision addresses all the WGLC comments received on the ver 07 of draft.=20 Summary of major things addressed: Comments received from Chritser, Marc, Christian among others. Removed the Liveness portion from the document as per the discussions in the mailer -=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg13135.html Clarified on scope of Consent (Consent is for sender of data/media) Editorial changes by Martin to make the text simple (with out changing the functionality or Algorithm). Diff:=20 http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshness= -0 8 Regards, Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Monday, 27 October 2014 9:43 pm To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Real-Time Communication in WEB-browsers >Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-08.txt > Pages : 9 > Date : 2014-10-27 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new Session > Traversal Utilities for NAT (STUN) usage. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-08 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshnes= s- >08 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Oct 27 09:52:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7811D1A1A31 for ; Mon, 27 Oct 2014 09:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-fpAfKt9RM0 for ; Mon, 27 Oct 2014 09:52:23 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140351A1A1B for ; Mon, 27 Oct 2014 09:51:32 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so6166871wgh.22 for ; Mon, 27 Oct 2014 09:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=QsvyEuKqqbNmHJLRAAub5Lg48010jbo8t69dvK9kQoI=; b=OHNnHcKZwaDPPyW0ntQweHZuwMtL4Q8p0uEfIZXHg2CfCDqz8K7lWAXcinDgIb3rKq cIz0u03cXreJHfrso0cxyNHeEoaudjHX6GvhN+58sxrnwiifP6/AE4TiqegkdWE/T9Rh qjIsjUc2KN7k8gBFBUIe3Buwbx+ILk4U5RebSH5DgOIEdoH9eGIDBr2djfTOJZsOePJN 4fODmfm4Ng5sBNv4oyPt6b3W0KncQM6fq9YF6NxG7c7PHdwQ+Oj2wPed7pG8dc8rligK m7vV/U1hZopdhI5gxGRrPtnMe38jubnuT+0SunfNJMrW+VHh6UarUjbaMP3i2Cl3DPtQ i8dQ== X-Received: by 10.194.209.230 with SMTP id mp6mr16780866wjc.2.1414428691531; Mon, 27 Oct 2014 09:51:31 -0700 (PDT) Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id yr9sm16187005wjc.31.2014.10.27.09.51.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 09:51:30 -0700 (PDT) Message-ID: <544E781D.50305@gmail.com> Date: Mon, 27 Oct 2014 17:51:41 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Colin Perkins References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> In-Reply-To: <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> Content-Type: multipart/alternative; boundary="------------010507060802070206040809" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/64R0GiWwf0rIllauA1WY_PmFmXo Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 16:52:26 -0000 This is a multi-part message in MIME format. --------------010507060802070206040809 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 27/10/2014 17:45, Colin Perkins wrote: > On 27 Oct 2014, at 16:40, Sergio Garcia Murillo > > wrote: >> On 27/10/2014 17:36, Colin Perkins wrote: >>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo >>> >> > wrote: >>>> Not sure if it is done on pourpose, but according to the RTP usage >>>> draft, it may seem that full RFC 4588 is mandated at the recevier side: >>>> >>>> Receivers are REQUIRED to implement support for RTP retransmission >>>> packets [RFC4588 ]. >>>> >>>> That would include both modes, session and ssrc multiplexing. Given >>>> the extensive usage of bundle and current implementations, session >>>> multiplexing support doesn't make much sense. >>>> >>>> Should we drop it, and state that only ssrc-multiplexing shall be >>>> supported at the receiving end? >>> >>> I don’t see any advantage to doing so, given that support for >>> non-BUNDLE sessions is REQUIRED. You need to implement the >>> signalling needed for session-multiplexing of retransmission packet >>> anyway, so disallowing it buys you nothing. >> >> You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, >> what I don't see is how to do session multiplexing with BUNDLE sessions. > > You can’t do session multiplexing for BUNDLE sessions; by definition > they use SSRC multiplexing. You could do non-BUNDLE sessions, with > retransmission sent on a separate RTP session though. > So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit. Also, the original discussion came from the ORTC list, as ORTC API only supports ssrc-multiplexing RTX. If we require both modes on WebRTC "just for fun", then ORTC API will not be able to comply with the RTP usage draft. Best regards Sergio --------------010507060802070206040809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 27/10/2014 17:45, Colin Perkins wrote:
On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don’t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can’t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Also, the original discussion came from the ORTC list, as ORTC API only supports ssrc-multiplexing RTX. If we require both modes on WebRTC "just for fun", then ORTC API will not be able to comply with the RTP usage draft.

Best regards
Sergio
--------------010507060802070206040809-- From nobody Mon Oct 27 10:12:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62DE1A6FDD for ; Mon, 27 Oct 2014 10:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QE6La84A5DWb for ; Mon, 27 Oct 2014 10:12:40 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5881A6F80 for ; Mon, 27 Oct 2014 10:10:50 -0700 (PDT) Received: from [130.209.247.112] (port=60320 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xinod-0003l5-Sj; Mon, 27 Oct 2014 17:10:48 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_1EBC4EB5-4902-496C-88C9-AC65E685503A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <544E781D.50305@gmail.com> Date: Mon, 27 Oct 2014 17:10:45 +0000 Message-Id: <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7q-TFMbA5qDUVoDcpQ_OMqLPiEI Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 17:12:43 -0000 --Apple-Mail=_1EBC4EB5-4902-496C-88C9-AC65E685503A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 27 Oct 2014, at 16:51, Sergio Garcia Murillo = wrote: > On 27/10/2014 17:45, Colin Perkins wrote: >> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo = wrote: >>> On 27/10/2014 17:36, Colin Perkins wrote: >>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo = wrote: >>>>> Not sure if it is done on pourpose, but according to the RTP usage = draft, it may seem that full RFC 4588 is mandated at the recevier side: >>>>>=20 >>>>> Receivers are REQUIRED to implement support for RTP = retransmission >>>>> packets [RFC4588]. >>>>>=20 >>>>> That would include both modes, session and ssrc multiplexing. = Given the extensive usage of bundle and current implementations, session = multiplexing support doesn't make much sense. >>>>>=20 >>>>> Should we drop it, and state that only ssrc-multiplexing shall be = supported at the receiving end? >>>>=20 >>>> I don=92t see any advantage to doing so, given that support for = non-BUNDLE sessions is REQUIRED. You need to implement the signalling = needed for session-multiplexing of retransmission packet anyway, so = disallowing it buys you nothing. >>>=20 >>> You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, = what I don't see is how to do session multiplexing with BUNDLE sessions.=20= >>=20 >> You can=92t do session multiplexing for BUNDLE sessions; by = definition they use SSRC multiplexing. You could do non-BUNDLE sessions, = with retransmission sent on a separate RTP session though. >>=20 > So, you are saying exactly the same than me. SSRC multiplexing = supports both BUNDLE and NON-BUNDLE. So, why require support for session = multiplexing at all? As a developer, I don't see why I would have to = implement something that would be rarely used and provide no extra = benefit. Non-BUNDLE is session multiplexing. It uses a separate RTP session for = the retransmissions.=20 > Also, the original discussion came from the ORTC list, as ORTC API = only supports ssrc-multiplexing RTX. If we require both modes on WebRTC = "just for fun", then ORTC API will not be able to comply with the RTP = usage draft. I=92m perhaps missing something, but it seems that the features needed = for session-multiplexed retransmission are required anyway (a=3Dgroup, = plus the ability to send non-BUNDLE media).=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_1EBC4EB5-4902-496C-88C9-AC65E685503A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 27 = Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
=20 =20
On 27/10/2014 17:45, Colin Perkins wrote:
On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
Not sure = if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are =
REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don=92t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=92t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE = is session multiplexing. It uses a separate RTP session for the = retransmissions. 

Also, the original discussion came from the ORTC list, as ORTC API only supports ssrc-multiplexing RTX. If we require both modes on WebRTC "just for fun", then ORTC API will not be able to comply with the RTP usage draft.

I=92m = perhaps missing something, but it seems that the features needed for = session-multiplexed retransmission are required anyway (a=3Dgroup, plus = the ability to send non-BUNDLE media). 

-- 
Colin Perkins

<= /div>


= --Apple-Mail=_1EBC4EB5-4902-496C-88C9-AC65E685503A-- From nobody Mon Oct 27 10:17:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C161A6F58 for ; Mon, 27 Oct 2014 10:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOiK1NImc-DT for ; Mon, 27 Oct 2014 10:17:37 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078741A6F90 for ; Mon, 27 Oct 2014 10:17:23 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id a1so2487038wgh.18 for ; Mon, 27 Oct 2014 10:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=1C3VHM75ty/ehUHG9Yrje2ZzXOTJCbT+Y35UW+lSa7A=; b=gRJZKeAe2IYPk0ulXcczOESOLS0eQfg2luaLYvrNLQibrWydeIMBH7iSF8c4lV0Mfb b4//7cNjnUdp43mj+/6ZzvLAYMA2i791iRR/xVNnlteFj9SX4kPTIwWxDkyz+6BG9TPn cmluy20f6bH/rWVX5IM+7CJD0R6EOS2nqmSYXuvn04o+6+xWLSr+iz5Mumk65sXvMCgv aJAowhfJS14ofJcEutjdUVeZKCRTA13cMqAsbpIUgid5sE2ql9EMPH4uj10liA/acj2k yXcHqUmFI8oWqX32Dk9uJhGoioz0HGPQ7rPyfb56Vs5xxap+k40wI5SOrWIh0e3NCCEl brrA== X-Received: by 10.194.85.229 with SMTP id k5mr22991205wjz.19.1414430242241; Mon, 27 Oct 2014 10:17:22 -0700 (PDT) Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id l10sm12530116wif.20.2014.10.27.10.17.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 10:17:21 -0700 (PDT) Message-ID: <544E7E2B.6040809@gmail.com> Date: Mon, 27 Oct 2014 18:17:31 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Colin Perkins References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> In-Reply-To: <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> Content-Type: multipart/alternative; boundary="------------090509010505020809070501" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VXbEHxysPrNwqidz23Sz0zPVftE Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 17:17:39 -0000 This is a multi-part message in MIME format. --------------090509010505020809070501 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 27/10/2014 18:10, Colin Perkins wrote: > On 27 Oct 2014, at 16:51, Sergio Garcia Murillo > > wrote: >> On 27/10/2014 17:45, Colin Perkins wrote: >>> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo >>> >> > wrote: >>>> On 27/10/2014 17:36, Colin Perkins wrote: >>>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo >>>>> >>>> > wrote: >>>>>> Not sure if it is done on pourpose, but according to the RTP >>>>>> usage draft, it may seem that full RFC 4588 is mandated at the >>>>>> recevier side: >>>>>> >>>>>> Receivers are REQUIRED to implement support for RTP retransmission >>>>>> packets [RFC4588 ]. >>>>>> >>>>>> That would include both modes, session and ssrc multiplexing. >>>>>> Given the extensive usage of bundle and current implementations, >>>>>> session multiplexing support doesn't make much sense. >>>>>> >>>>>> Should we drop it, and state that only ssrc-multiplexing shall be >>>>>> supported at the receiving end? >>>>> >>>>> I don’t see any advantage to doing so, given that support for >>>>> non-BUNDLE sessions is REQUIRED. You need to implement the >>>>> signalling needed for session-multiplexing of retransmission >>>>> packet anyway, so disallowing it buys you nothing. >>>> >>>> You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, >>>> what I don't see is how to do session multiplexing with BUNDLE >>>> sessions. >>> >>> You can’t do session multiplexing for BUNDLE sessions; by definition >>> they use SSRC multiplexing. You could do non-BUNDLE sessions, with >>> retransmission sent on a separate RTP session though. >>> >> So, you are saying exactly the same than me. SSRC multiplexing >> supports both BUNDLE and NON-BUNDLE. So, why require support for >> session multiplexing at all? As a developer, I don't see why I would >> have to implement something that would be rarely used and provide no >> extra benefit. > > Non-BUNDLE is session multiplexing. It uses a separate RTP session for > the retransmissions. Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different things? > >> Also, the original discussion came from the ORTC list, as ORTC API >> only supports ssrc-multiplexing RTX. If we require both modes on >> WebRTC "just for fun", then ORTC API will not be able to comply with >> the RTP usage draft. > > I’m perhaps missing something, but it seems that the features needed > for session-multiplexed retransmission are required anyway (a=group, > plus the ability to send non-BUNDLE media). > In current ORTC API, the RTX parameters are configured on the RTPReceiver/Sender object used for the media. Best regards Sergio --------------090509010505020809070501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 27/10/2014 18:10, Colin Perkins wrote:
On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 17:45, Colin Perkins wrote:
On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don’t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can’t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE is session multiplexing. It uses a separate RTP session for the retransmissions.
Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different things?


Also, the original discussion came from the ORTC list, as ORTC API only supports ssrc-multiplexing RTX. If we require both modes on WebRTC "just for fun", then ORTC API will not be able to comply with the RTP usage draft.

I’m perhaps missing something, but it seems that the features needed for session-multiplexed retransmission are required anyway (a=group, plus the ability to send non-BUNDLE media). 


In current ORTC API, the RTX parameters are configured on the RTPReceiver/Sender object used for the media.

Best regards
Sergio
--------------090509010505020809070501-- From nobody Mon Oct 27 11:11:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2DD1A8956 for ; Mon, 27 Oct 2014 11:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br2iMJMDNBMK for ; Mon, 27 Oct 2014 11:10:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C639A1A894A for ; Mon, 27 Oct 2014 11:10:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-59-544e8a9c78ab Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DA.87.04387.C9A8E445; Mon, 27 Oct 2014 19:10:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 19:10:35 +0100 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions Thread-Index: Ac/yEUlFgzg9keX0RtqfGQOICUeeIw== Date: Mon, 27 Oct 2014 18:10:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje6cLr8QgzUNshbLu3YwWqz9187u wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGV07jjBWnBdsGLRnFusDYy3ebsYOTkkBEwk drV9Y4ewxSQu3FvP1sXIxSEkcIRRYtvMW4wQzhJGiYMPJ7F2MXJwsAlYSHT/0wZpEBEIk5h+ YgELiC0skC/RenQSO0S8QOJ0wxlGCFtP4tbMiUwgNouAqsSpF2vB6nkFfCWezv0LFmcEWvz9 1Bowm1lAXOLWk/lMEAcJSCzZc54ZwhaVePn4HyuErSSx6PZnqHodiQW7P7FB2NoSyxa+ZoaY LyhxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAgM +4NbflvtYDz43PEQowAHoxIP74ca3xAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cBoVib1vJN74TVV+aCQU9/tLUQa2Be9XicRIaDIYdTJ32z/UOp82GkG N69tLbYRBxezvhco67l24dbpBytuPBeRlJ+0c3PuR+kUza8Gai5xZ/aKmeiznNPU4osuVTdX ClTcc0BuywLuq3IayV+PqZvzbThsutDQcWPLbsFKo8/ld+37/+jKP1FiKc5INNRiLipOBAD0 smaoXAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O1Hk9vFmfj4VnKLxyrBw029Hw4M Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 18:10:44 -0000 Hi, Thanks for putting together the new version! It makes a number of things mo= re clear :) I do still have a few comments/questions (hopefully editorial ones), though= : Q1: ----- I think it would be good to explicitly clarify that, when consent expires o= n a 5-tuple/candidate pair, it does not affect other 5-tuples within the se= ssion. I have received questions on that, so I think some words would be us= eful to make it more clear. (Of course, one CAN choose to terminate the whole session if consent expire= s on a candidate pair, but that depends on application policy). Q2: ----- If consent expires, and I stop sending application data, will I still send = STUN keep-alives etc, to keep the candidate pair, NAT bindings etc alive?=20 There IS text saying: "An endpoint that is not sending any application data does not need to maintain consent. However, the endpoint needs to ensure its NAT or firewall mappings persist which can be done using keepalive or other techniques (see Section 10 of [RFC5245] and see [RFC6263])." However, that seems to be more related to cases where I don't intend to sen= d application data to begin with. So, perhaps the text above can be modified, to clarify that keepalives etc = will still be sent if consent expires. Q3: ----- Section 4.1. says: "If the endpoint wants to send application data, it needs to first obtain consent if its consent has expired." If my consent has expired, is the a time period before I can try to obtain = consent again? Can I just continue sending STUN binding requests even if my= consent expires, and wait to obtain consent again? (I obviously won't send any application data until I obtain consent again.) Q4: ----- When my consent expires, is it considered an error if I also choose to not = receive any data? If not, I think it would be good to indicate that one may= choose to also stop receiving data in case consent expires. Q5: ----- Assuming I send RTP and RTCP on separate 5-tuples, and consent expires on o= ne of the 5-tuples. I assume that will impact both 5-tuples, and in that ca= se I think it would be good to clarify. Thanks! Regards, Christer From nobody Mon Oct 27 11:27:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66D81A8AB0 for ; Mon, 27 Oct 2014 11:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_wnKBvGRVqR for ; Mon, 27 Oct 2014 11:26:55 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC161A035F for ; Mon, 27 Oct 2014 11:23:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 500C27C5B00 for ; Mon, 27 Oct 2014 19:23:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IORGfVRpqmHF for ; Mon, 27 Oct 2014 19:23:17 +0100 (CET) Received: from [172.20.47.18] (unknown [12.199.206.2]) by mork.alvestrand.no (Postfix) with ESMTPSA id 02CB57C5AF5 for ; Mon, 27 Oct 2014 19:23:16 +0100 (CET) Message-ID: <544E8D92.8010401@alvestrand.no> Date: Mon, 27 Oct 2014 11:23:14 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qfEm448MnIcFDXOZBddAyckeg24 Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 18:27:00 -0000 On 10/27/2014 07:19 AM, Christer Holmberg wrote: > Hi, > >>> Within the CLUE WG, we had a discussion regarding the following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>> >>> "The support for message interleaving as defined in >>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>> >>> First, it is a little unclear what "the support SHOULD be used" means. >> My understanding is that SCTP implementations supporting the extension will use it. >> This is negotiated during the setup of the SCTP association. > If it's done on SCTP level, why do we need to talk about it in the data channel draft? > > Is there a reason why it is important to use it for data channels? If so, does it apply to data channels in general? NDATA was added in order to avoid head-of-line blocking on the transport (if I understand this correctly, until this was added, sending a huge message would block the delivery of small messages on all channels until the huge message was fully delivered). Unlike Michael, I see no reason to make this a SHOULD; I think it should be a MUST, and the older implementations in browsers should just be called out as non-conformant. That said, I think that data channels ought to interoperate successfully with implementations that don't support the extension - but data channel implementations in WebRTC endpoints should be under a "MUST implement, MUST offer" ruleset. > > Regards, > > Christer > > > > Whether messages are interleaved or not depends on the stream scheduler. This is a sender side only decision. The receiver has to deal with it. > It is not a MUST, since there are implementations now in use which don't support the extension. > > Best regards > Michael >> >> Second, does it mean that any data channel protocol (e.g CLUE) SHOULD use interleaving, even if the characteristics of the protocol wouldn't require it? >> >> Regards, >> >> Christer >> _______________________________________________ >> 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 -- Surveillance is pervasive. Go Dark. From nobody Mon Oct 27 11:44:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938391ACE86 for ; Mon, 27 Oct 2014 11:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfgeDVfAt_UH for ; Mon, 27 Oct 2014 11:44:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF4B1A924C for ; Mon, 27 Oct 2014 11:41:20 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-39-544e91cef7b1 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 23.99.04387.EC19E445; Mon, 27 Oct 2014 19:41:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 19:41:18 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3////5gA///tr8CAAFjuAP//7KkQ Date: Mon, 27 Oct 2014 18:41:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> In-Reply-To: <544E8D92.8010401@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje75iX4hBotbOSyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGW0XHrEVNAnUdF7eQtbA+Ne4S5GTg4JAROJ xk0T2CFsMYkL99azdTFycQgJHGGUOPP3MZSzhFFiUv8Bli5GDg42AQuJ7n/aIA0iAsESvc/f M4LYwgIOEmd3TmKHiDtKtL09zwRhu0nsv/iEBcRmEVCVOH3pJyuIzSvgK7FsRxPU/PeMEou+ 3gBr5hTQlZi8bCFYESPQRd9PrQEbxCwgLnHryXwmiEsFJJbsOc8MYYtKvHz8jxXCVpJYdPsz VL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYX56Yb GemlFmUmFxfn5+nlpZZsYgRGysEtv612MB587niIUYCDUYmH90ONb4gQa2JZcWXuIUZpDhYl cd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDsZtCzb6mOa5DUm5Erp+NyY1LaxrC9 rWfmLJDmn7LzaWuCEJPcKp1E7pTiyXobdvdw+2SYn+p45HxsTvuLxGlyC38zq3GsO6ZqMl30 2RGZM5w+4jzB9T/mHj66NUQ27xDD+cA+xyXawdUMC/iXZjZs0p0pdzk587dkJ1dEiWjd1HV3 n8l5XlNiKc5INNRiLipOBAB4YqjvdQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iU9uW2Lzq-EnOMH9y--3vnMxbk4 Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 18:44:20 -0000 Hi, >>>> Within the CLUE WG, we had a discussion regarding the following statem= ent in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>> =20 >>>> "The support for message interleaving as defined in >>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>> =20 >>>> First, it is a little unclear what "the support SHOULD be used" means. >>> My understanding is that SCTP implementations supporting the extension = will use it. >>> This is negotiated during the setup of the SCTP association. >> If it's done on SCTP level, why do we need to talk about it in the data = channel draft?=20 >> >> Is there a reason why it is important to use it for data channels? If so= , does it apply to data channels in general?=20 > > NDATA was added in order to avoid head-of-line blocking on the transport = (if I understand this correctly, until=20 > this was added, sending a huge message would block the delivery of small = messages on all channels until the huge message was fully delivered). > > Unlike Michael, I see no reason to make this a SHOULD; I think it should = be a MUST, and the older=20 > implementations in browsers should just be called out as non-conformant. > > That said, I think that data channels ought to interoperate successfully = with implementations that don't support the=20 > extension - but data channel implementations in WebRTC endpoints should b= e under a "MUST implement, MUST offer" ruleset. First, keep in mind that I am NOT talking about WebRTC endpoints (which is = one reason we shouldn't call it webrtc data channel to begin with, but that= 's another story...), but ANY type of endpoint that wants to use a data cha= nnel.=20 Second, I am not talking about MUST support, but MUST use/offer. Assume I have a CLUE endpoint, which will use a data channel ONLY to transp= ort CLUE messages. CLUE messages aren't that hugeto begin with, and there w= ill be no blocking of small messages on other channels - as there are no ot= her channels. So, why does the CLUE endpoint need to offer interleaving? Regards, Christer > Whether messages are interleaved or not depends on the stream scheduler. = This is a sender side only decision. The receiver has to deal with it. > It is not a MUST, since there are implementations now in use which don't = support the extension. > > Best regards > Michael >> =20 >> Second, does it mean that any data channel protocol (e.g CLUE) SHOULD us= e interleaving, even if the characteristics of the protocol wouldn't requir= e it? >> =20 >> Regards, >> =20 >> Christer >> _______________________________________________ >> 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 -- Surveillance is pervasive. Go Dark. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Oct 27 12:17:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C021A039D for ; Mon, 27 Oct 2014 12:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLZILALFMjuP for ; Mon, 27 Oct 2014 12:16:45 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2501A038E for ; Mon, 27 Oct 2014 12:16:44 -0700 (PDT) Received: from [81.187.2.149] (port=34845 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XipmT-0002eW-Rs; Mon, 27 Oct 2014 19:16:42 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_F0FBFB17-07D7-484B-BB29-D25DBC347429" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <544E7E2B.6040809@gmail.com> Date: Mon, 27 Oct 2014 19:16:38 +0000 Message-Id: <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> <544E7E2B.6040809@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gbBSkv3iQk55xaFM_3eCP6UfFkQ Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 19:16:48 -0000 --Apple-Mail=_F0FBFB17-07D7-484B-BB29-D25DBC347429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 27 Oct 2014, at 17:17, Sergio Garcia Murillo = wrote: > On 27/10/2014 18:10, Colin Perkins wrote: >> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo = wrote: >>> On 27/10/2014 17:45, Colin Perkins wrote: >>>> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo = wrote: >>>>> On 27/10/2014 17:36, Colin Perkins wrote: >>>>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo = wrote: >>>>>>> Not sure if it is done on pourpose, but according to the RTP = usage draft, it may seem that full RFC 4588 is mandated at the recevier = side: >>>>>>>=20 >>>>>>> Receivers are REQUIRED to implement support for RTP = retransmission >>>>>>> packets [RFC4588]. >>>>>>>=20 >>>>>>> That would include both modes, session and ssrc multiplexing. = Given the extensive usage of bundle and current implementations, session = multiplexing support doesn't make much sense. >>>>>>>=20 >>>>>>> Should we drop it, and state that only ssrc-multiplexing shall = be supported at the receiving end? >>>>>>=20 >>>>>> I don=92t see any advantage to doing so, given that support for = non-BUNDLE sessions is REQUIRED. You need to implement the signalling = needed for session-multiplexing of retransmission packet anyway, so = disallowing it buys you nothing. >>>>>=20 >>>>> You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, = what I don't see is how to do session multiplexing with BUNDLE sessions.=20= >>>>=20 >>>> You can=92t do session multiplexing for BUNDLE sessions; by = definition they use SSRC multiplexing. You could do non-BUNDLE sessions, = with retransmission sent on a separate RTP session though. >>>>=20 >>> So, you are saying exactly the same than me. SSRC multiplexing = supports both BUNDLE and NON-BUNDLE. So, why require support for session = multiplexing at all? As a developer, I don't see why I would have to = implement something that would be rarely used and provide no extra = benefit. >>=20 >> Non-BUNDLE is session multiplexing. It uses a separate RTP session = for the retransmissions.=20 > Maybe I am the missing something, if you don't use bundle to send the = audio/video on same rtpsession, you can still send rtx+video on same = session. That's it non-bundle with ssrc-multiplexing. Are we referring = to different things? Sure, but that doesn=92t alter the fact that the group decided that = non-BUNDLE media needs to be supported. Sending retransmission on a = separate RTP session is as needed for interoperability with legacy = systems as sending audio and video on separate RTP sessions (and = shouldn=92t be hard to support, since it uses the same mechanisms). Colin --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_F0FBFB17-07D7-484B-BB29-D25DBC347429 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 27 = Oct 2014, at 17:17, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
=20 =20
On 27/10/2014 18:10, Colin Perkins wrote:
On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
On 27/10/2014 17:45, Colin Perkins wrote:
On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are =
REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don=92t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=92t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE is session multiplexing. It uses a separate RTP session for the retransmissions.
Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different = things?

Sure, but that doesn=92t = alter the fact that the group decided that non-BUNDLE media needs to be = supported. Sending retransmission on a separate RTP session is as needed = for interoperability with legacy systems as sending audio and video on = separate RTP sessions (and shouldn=92t be hard to support, since it uses = the same = mechanisms).

Colin


<= /div>

-- 
Colin Perkins

<= /div>


= --Apple-Mail=_F0FBFB17-07D7-484B-BB29-D25DBC347429-- From nobody Mon Oct 27 12:26:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF6E1AD218; Mon, 27 Oct 2014 12:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSIdvYhHwEY2; Mon, 27 Oct 2014 12:26:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 536D21AD0D7; Mon, 27 Oct 2014 12:26:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027192601.3639.27651.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 12:26:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ofRlWgBv8m7bkweq7zAUUnzsK9o Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-19.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 19:26:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Authors : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-19.txt Pages : 44 Date : 2014-10-27 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 12:34:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93831A0386 for ; Mon, 27 Oct 2014 12:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lylqSi-BwmNb for ; Mon, 27 Oct 2014 12:33:26 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC9B1AD2F6 for ; Mon, 27 Oct 2014 12:33:24 -0700 (PDT) Received: from [81.187.2.149] (port=36658 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xiq2b-0004Yf-Pb for rtcweb@ietf.org; Mon, 27 Oct 2014 19:33:22 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <20141027192601.3639.27651.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 19:33:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141027192601.3639.27651.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZnU7l21pBk_bnds_2A5QlWowjzc Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-19.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 19:33:31 -0000 This version clarifies that RTP retransmission has to be supported in = both session and SSRC multiplexed mode (i.e., non-BUNDLE and BUNDLE = modes). The aim is to make what I believe is the consensus clear in the = draft. If this is not the consensus of the group, then we can update = this draft. Colin On 27 Oct 2014, at 19:26, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Authors : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-19.txt > Pages : 44 > Date : 2014-10-27 >=20 > Abstract: > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-19 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-19 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins https://csperkins.org/ From nobody Mon Oct 27 12:40:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122A81ACFF2; Mon, 27 Oct 2014 12:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XriLa8JHmwTk; Mon, 27 Oct 2014 12:40:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DD41ACFBA; Mon, 27 Oct 2014 12:40:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027194003.3681.85892.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 12:40:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QSHgpRGYALMekXCOcgHLOv9ukLM Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 19:40:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-08.txt Pages : 65 Date : 2014-10-27 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 12:50:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC131AD0BE for ; Mon, 27 Oct 2014 12:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJr4C-pZSz9l for ; Mon, 27 Oct 2014 12:50:02 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A9F1AD0D7 for ; Mon, 27 Oct 2014 12:50:01 -0700 (PDT) Received: from [192.168.1.200] (p508F0FB4.dip0.t-ipconnect.de [80.143.15.180]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C8D8F1C104D97; Mon, 27 Oct 2014 20:49:59 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> Date: Mon, 27 Oct 2014 20:49:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PXRVuUxisDIfh-PCVbqm6XpNoZ4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 19:50:03 -0000 On 27 Oct 2014, at 15:19, Christer Holmberg = wrote: > Hi, >=20 >>> Within the CLUE WG, we had a discussion regarding the following = statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>=20 >>> "The support for message interleaving as defined in >>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>=20 >>> First, it is a little unclear what "the support SHOULD be used" = means. >>=20 >> My understanding is that SCTP implementations supporting the = extension will use it. >> This is negotiated during the setup of the SCTP association. >=20 > If it's done on SCTP level, why do we need to talk about it in the = data channel draft?=20 We need to specify somewhere that the extension is used and how to map = the priorities of data channels to some protocol mechanism. This is done in this = document. >=20 > Is there a reason why it is important to use it for data channels? If = so, does it apply to data channels in general?=20 As it is written right now: yes. Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > Whether messages are interleaved or not depends on the stream = scheduler. This is a sender side only decision. The receiver has to deal = with it. > It is not a MUST, since there are implementations now in use which = don't support the extension. >=20 > Best regards > Michael >>=20 >> Second, does it mean that any data channel protocol (e.g CLUE) SHOULD = use interleaving, even if the characteristics of the protocol wouldn't = require it? >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 From nobody Mon Oct 27 12:52:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0456F1AD365 for ; Mon, 27 Oct 2014 12:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwJlfm3n3PSg for ; Mon, 27 Oct 2014 12:52:16 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AEB1AD350 for ; Mon, 27 Oct 2014 12:52:10 -0700 (PDT) Received: from [192.168.1.200] (p508F0FB4.dip0.t-ipconnect.de [80.143.15.180]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4477F1C104FDB; Mon, 27 Oct 2014 20:52:08 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <544E8D92.8010401@alvestrand.no> Date: Mon, 27 Oct 2014 20:52:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <563F290F-107A-4D1D-9702-1612ECA4AA03@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0cCOJCwv8PIIOdNMFKFxhyX0ev8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 19:52:19 -0000 On 27 Oct 2014, at 19:23, Harald Alvestrand = wrote: > On 10/27/2014 07:19 AM, Christer Holmberg wrote: >> Hi, >>=20 >>>> Within the CLUE WG, we had a discussion regarding the following = statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>>=20 >>>> "The support for message interleaving as defined in >>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>>=20 >>>> First, it is a little unclear what "the support SHOULD be used" = means. >>> My understanding is that SCTP implementations supporting the = extension will use it. >>> This is negotiated during the setup of the SCTP association. >> If it's done on SCTP level, why do we need to talk about it in the = data channel draft?=20 >>=20 >> Is there a reason why it is important to use it for data channels? If = so, does it apply to data channels in general?=20 >=20 > NDATA was added in order to avoid head-of-line blocking on the = transport > (if I understand this correctly, until this was added, sending a huge > message would block the delivery of small messages on all channels = until > the huge message was fully delivered). >=20 > Unlike Michael, I see no reason to make this a SHOULD; I think it = should > be a MUST, and the older implementations in browsers should just be > called out as non-conformant. I personally also prefer a MUST, but the reason I gave was the one which was used in the discussion resulting in a SHOULD. Since this is also = brought up by David, we possibly need to reconsider the issue and change it to a = MUST. Best regards Michael >=20 > That said, I think that data channels ought to interoperate = successfully > with implementations that don't support the extension - but data = channel > implementations in WebRTC endpoints should be under a "MUST implement, > MUST offer" ruleset. >=20 >=20 >=20 >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> Whether messages are interleaved or not depends on the stream = scheduler. This is a sender side only decision. The receiver has to deal = with it. >> It is not a MUST, since there are implementations now in use which = don't support the extension. >>=20 >> Best regards >> Michael >>>=20 >>> Second, does it mean that any data channel protocol (e.g CLUE) = SHOULD use interleaving, even if the characteristics of the protocol = wouldn't require it? >>>=20 >>> Regards, >>>=20 >>> Christer >>> _______________________________________________ >>> 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 >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Oct 27 12:55:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E5A1AD3A0 for ; Mon, 27 Oct 2014 12:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NSlXLkNPDR5 for ; Mon, 27 Oct 2014 12:55:23 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB111AD392 for ; Mon, 27 Oct 2014 12:55:19 -0700 (PDT) Received: from [192.168.1.200] (p508F0FB4.dip0.t-ipconnect.de [80.143.15.180]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 87DA81C104D97; Mon, 27 Oct 2014 20:55:17 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> Date: Mon, 27 Oct 2014 20:55:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DnMZ2u6XdQl2sP_LN8a23LiHWV4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 19:55:25 -0000 On 27 Oct 2014, at 19:41, Christer Holmberg = wrote: > Hi, >=20 >>>>> Within the CLUE WG, we had a discussion regarding the following = statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>>>=20 >>>>> "The support for message interleaving as defined in >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>>>=20 >>>>> First, it is a little unclear what "the support SHOULD be used" = means. >>>> My understanding is that SCTP implementations supporting the = extension will use it. >>>> This is negotiated during the setup of the SCTP association. >>> If it's done on SCTP level, why do we need to talk about it in the = data channel draft?=20 >>>=20 >>> Is there a reason why it is important to use it for data channels? = If so, does it apply to data channels in general?=20 >>=20 >> NDATA was added in order to avoid head-of-line blocking on the = transport (if I understand this correctly, until=20 >> this was added, sending a huge message would block the delivery of = small messages on all channels until the huge message was fully = delivered). >>=20 >> Unlike Michael, I see no reason to make this a SHOULD; I think it = should be a MUST, and the older=20 >> implementations in browsers should just be called out as = non-conformant. >>=20 >> That said, I think that data channels ought to interoperate = successfully with implementations that don't support the=20 >> extension - but data channel implementations in WebRTC endpoints = should be under a "MUST implement, MUST offer" ruleset. >=20 > First, keep in mind that I am NOT talking about WebRTC endpoints = (which is one reason we shouldn't call it webrtc data channel to begin = with, but that's another story...), but ANY type of endpoint that wants = to use a data channel.=20 >=20 > Second, I am not talking about MUST support, but MUST use/offer. >=20 > Assume I have a CLUE endpoint, which will use a data channel ONLY to = transport CLUE messages. CLUE messages aren't that hugeto begin with, = and there will be no blocking of small messages on other channels - as = there are no other channels. >=20 > So, why does the CLUE endpoint need to offer interleaving? As far as I know we don't have different flavours of data channels. At = least right now. Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 >> Whether messages are interleaved or not depends on the stream = scheduler. This is a sender side only decision. The receiver has to deal = with it. >> It is not a MUST, since there are implementations now in use which = don't support the extension. >>=20 >> Best regards >> Michael >>>=20 >>> Second, does it mean that any data channel protocol (e.g CLUE) = SHOULD use interleaving, even if the characteristics of the protocol = wouldn't require it? >>>=20 >>> Regards, >>>=20 >>> Christer >>> _______________________________________________ >>> 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 >=20 > -- > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > 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 >=20 From nobody Mon Oct 27 13:01:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAD31AD3E8 for ; Mon, 27 Oct 2014 13:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak3F74LG8XVt for ; Mon, 27 Oct 2014 13:00:56 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 63C501AD3D4 for ; Mon, 27 Oct 2014 13:00:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7300A7C5A4B; Mon, 27 Oct 2014 21:00:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23urbsMqQzIY; Mon, 27 Oct 2014 21:00:54 +0100 (CET) Received: from [172.20.47.18] (unknown [12.199.206.2]) by mork.alvestrand.no (Postfix) with ESMTPSA id BB5D17C59B3; Mon, 27 Oct 2014 21:00:53 +0100 (CET) Message-ID: <544EA473.6040700@alvestrand.no> Date: Mon, 27 Oct 2014 13:00:51 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fAoN2__SpamEPf7dY7DkCUC8AJ4 Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:01:02 -0000 On 10/27/2014 11:41 AM, Christer Holmberg wrote: > Hi, > >>>>> Within the CLUE WG, we had a discussion regarding the following sta= tement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>>> =20 >>>>> "The support for message interleaving as defined in >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>>> =20 >>>>> First, it is a little unclear what "the support SHOULD be used" mea= ns. >>>> My understanding is that SCTP implementations supporting the extensi= on will use it. >>>> This is negotiated during the setup of the SCTP association. >>> If it's done on SCTP level, why do we need to talk about it in the da= ta channel draft?=20 >>> >>> Is there a reason why it is important to use it for data channels? If= so, does it apply to data channels in general?=20 >> NDATA was added in order to avoid head-of-line blocking on the transpo= rt (if I understand this correctly, until=20 >> this was added, sending a huge message would block the delivery of sma= ll messages on all channels until the huge message was fully delivered). >> >> Unlike Michael, I see no reason to make this a SHOULD; I think it shou= ld be a MUST, and the older=20 >> implementations in browsers should just be called out as non-conforman= t. >> >> That said, I think that data channels ought to interoperate successful= ly with implementations that don't support the=20 >> extension - but data channel implementations in WebRTC endpoints shoul= d be under a "MUST implement, MUST offer" ruleset. > First, keep in mind that I am NOT talking about WebRTC endpoints (which= is one reason we shouldn't call it webrtc data channel to begin with, bu= t that's another story...), but ANY type of endpoint that wants to use a = data channel.=20 I'm a bit self-centric on behalf of WebRTC, but I feel the other way - that it might have been a mistake to float the option of saying "other things can use these features", and that we should admit only arguments that bear upon their usage in WebRTC. I'm not sure I have WG consensus (even rough consensus) on this point, however. > > Second, I am not talking about MUST support, but MUST use/offer. > > Assume I have a CLUE endpoint, which will use a data channel ONLY to tr= ansport CLUE messages. CLUE messages aren't that hugeto begin with, and t= here will be no blocking of small messages on other channels - as there a= re no other channels. > > So, why does the CLUE endpoint need to offer interleaving? Flipping the question around - if a programming mistake in the Javascript implementing a CLUE endpoint in a WebRTC browser happens to send a multimegabyte-sized object down the (out of order) datachannel, is it OK to have all the subsequent CLUE messages delivered 30 seconds la= te? --=20 Surveillance is pervasive. Go Dark. From nobody Mon Oct 27 13:06:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42411AD3F3 for ; Mon, 27 Oct 2014 13:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVP4avY92e13 for ; Mon, 27 Oct 2014 13:05:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177D11AD3D7 for ; Mon, 27 Oct 2014 13:05:55 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-a0-544ea5a2b45f Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 85.21.04231.2A5AE445; Mon, 27 Oct 2014 21:05:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 21:05:53 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3////5gA///tr8CAAFjuAP//7KkQgAAtDgCAABO7Sw== Date: Mon, 27 Oct 2014 20:05:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> In-Reply-To: <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4CEBABESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RnfRUr8Qgw33xCyO9XWxWVxsWsJo sfZfO7sDs8eVCVdYPZYs+cnksaFlB1MAcxSXTUpqTmZZapG+XQJXxoZZM9gLWiMrGjZfYmtg 3OfdxcjJISFgIrFp33JmCFtM4sK99WxdjFwcQgJHGCWu/9/LBOEsYZTYdWgdaxcjBwebgIVE 9z9tkAYRAVOJg8vnsYDYzALBEr1dk1lBbGEBB4mzOyexQ9Q4SrS9Pc8EYYdJLLwxG8xmEVCV mNC7gQ3E5hXwlWhYtokdYtcbJom+e5/AEpwCrhINDdfArmMEuu77qTVMEMvEJZq+rGSFuFpA Ysme81AfiEq8fPwP7E5mgXyJWRNVIOYLSpyc+YRlAqPILCTdsxCqZiGpgigxkPjy/jaUrS2x bOFrZghbX6L7/WkmZPEFjOyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQIj7eCW37o7GFe/ djzEKMDBqMTD+6HGN0SINbGsuDL3EKM0B4uSOO+ic/OChQTSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTDKL/qlb9vjydRoahHVv/ypyRv9pzG1udz2jU5FB/brMYs5yERYdTP/mT8xn4X9pbnc BM87F66sOfxtfz3/nNKJP1rVE932P736/Xd8mHv1mWtCIvZG7Y4cXF/82CelGGdzM4a08J/V K0urMv0jff9VpWu2cbspV1dZ+w21+SeDnn+35nmVpMRSnJFoqMVcVJwIANnUnb6VAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-sTQKMn7N8nm-bZfDlX_XFeGMag Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:05:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4CEBABESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I am not suggesting different flavors - I am suggesting to make the usage o= f interleaving optional. Other SCTP features are also optional (including r= eliability, ordering etc). We CAN write/reference guidelines on when it DOES make sense to use interle= aving. Regards, Christer Sent from my Windows Phone ________________________________ From: Michael Tuexen Sent: =FD27/=FD10/=FD2014 21:55 To: Christer Holmberg Cc: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving On 27 Oct 2014, at 19:41, Christer Holmberg wrote: > Hi, > >>>>> Within the CLUE WG, we had a discussion regarding the following state= ment in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>>> >>>>> "The support for message interleaving as defined in >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>>> >>>>> First, it is a little unclear what "the support SHOULD be used" means= . >>>> My understanding is that SCTP implementations supporting the extension= will use it. >>>> This is negotiated during the setup of the SCTP association. >>> If it's done on SCTP level, why do we need to talk about it in the data= channel draft? >>> >>> Is there a reason why it is important to use it for data channels? If s= o, does it apply to data channels in general? >> >> NDATA was added in order to avoid head-of-line blocking on the transport= (if I understand this correctly, until >> this was added, sending a huge message would block the delivery of small= messages on all channels until the huge message was fully delivered). >> >> Unlike Michael, I see no reason to make this a SHOULD; I think it should= be a MUST, and the older >> implementations in browsers should just be called out as non-conformant. >> >> That said, I think that data channels ought to interoperate successfully= with implementations that don't support the >> extension - but data channel implementations in WebRTC endpoints should = be under a "MUST implement, MUST offer" ruleset. > > First, keep in mind that I am NOT talking about WebRTC endpoints (which i= s one reason we shouldn't call it webrtc data channel to begin with, but th= at's another story...), but ANY type of endpoint that wants to use a data c= hannel. > > Second, I am not talking about MUST support, but MUST use/offer. > > Assume I have a CLUE endpoint, which will use a data channel ONLY to tran= sport CLUE messages. CLUE messages aren't that hugeto begin with, and there= will be no blocking of small messages on other channels - as there are no = other channels. > > So, why does the CLUE endpoint need to offer interleaving? As far as I know we don't have different flavours of data channels. At leas= t right now. Best regards Michael > > Regards, > > Christer > > >> Whether messages are interleaved or not depends on the stream scheduler.= This is a sender side only decision. The receiver has to deal with it. >> It is not a MUST, since there are implementations now in use which don't= support the extension. >> >> Best regards >> Michael >>> >>> Second, does it mean that any data channel protocol (e.g CLUE) SHOULD u= se interleaving, even if the characteristics of the protocol wouldn't requi= re it? >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> 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 > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > 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_7594FB04B1934943A5C02806D1A2204B1D4CEBABESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I am not suggesting different flavors - I am suggesting to make the usage o= f interleaving optional. Other SCTP features are also optional (including r= eliability, ordering etc).

We CAN write/reference guidelines on when it DOES make sense to use interle= aving.

Regards,

Christer

Sent from my Windows Phone
From: Michael Tuexen Sent: =FD27= /=FD10/=FD2014 21:55
To: Christer Holmberg Cc: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [= rtcweb] Meaning of SHOULD support/use interleaving

On 27 Oct 2014, at 19:41, Christer Holmberg <ch= rister.holmberg@ericsson.com> wrote:

> Hi,
>
>>>>> Within the CLUE WG, we had a discussion regarding the = following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt= :
>>>>>
>>>>> "The support for message interleaving as defined = in
>>>>>         &= nbsp;      [I-D.ietf-tsvwg-sctp-ndata] SHOULD be u= sed."
>>>>>
>>>>> First, it is a little unclear what "the support S= HOULD be used" means.
>>>> My understanding is that SCTP implementations supporting t= he extension will use it.
>>>> This is negotiated during the setup of the SCTP associatio= n.
>>> If it's done on SCTP level, why do we need to talk about it in= the data channel draft?
>>>
>>> Is there a reason why it is important to use it for data chann= els? If so, does it apply to data channels in general?
>>
>> NDATA was added in order to avoid head-of-line blocking on the tra= nsport (if I understand this correctly, until
>> this was added, sending a huge message would block the delivery of= small messages on all channels until the huge message was fully delivered)= .
>>
>> Unlike Michael, I see no reason to make this a SHOULD; I think it = should be a MUST, and the older
>> implementations in browsers should just be called out as non-confo= rmant.
>>
>> That said, I think that data channels ought to interoperate succes= sfully with implementations that don't support the
>> extension - but data channel implementations in WebRTC endpoints s= hould be under a "MUST implement, MUST offer" ruleset.
>
> First, keep in mind that I am NOT talking about WebRTC endpoints (whic= h is one reason we shouldn't call it webrtc data channel to begin with, but= that's another story...), but ANY type of endpoint that wants to use a dat= a channel.
>
> Second, I am not talking about MUST support, but MUST use/offer.
>
> Assume I have a CLUE endpoint, which will use a data channel ONLY to t= ransport CLUE messages. CLUE messages aren't that hugeto begin with, and th= ere will be no blocking of small messages on other channels - as there are = no other channels.
>
> So, why does the CLUE endpoint need to offer interleaving?
As far as I know we don't have different flavours of data channels. At leas= t right now.

Best regards
Michael
>
> Regards,
>
> Christer
>
>
>> Whether messages are interleaved or not depends on the stream sche= duler. This is a sender side only decision. The receiver has to deal with i= t.
>> It is not a MUST, since there are implementations now in use which= don't support the extension.
>>
>> Best regards
>> Michael
>>>
>>> Second, does it mean that any data channel protocol (e.g CLUE)= SHOULD use interleaving, even if the characteristics of the protocol would= n't require it?
>>>
>>> Regards,
>>>
>>> Christer
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https= ://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Surveillance is pervasive. Go Dark.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--_000_7594FB04B1934943A5C02806D1A2204B1D4CEBABESESSMB209erics_-- From nobody Mon Oct 27 13:11:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FB61A19F8 for ; Mon, 27 Oct 2014 13:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMKOB8_kwI1y for ; Mon, 27 Oct 2014 13:10:44 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346CD1AD40A for ; Mon, 27 Oct 2014 13:10:44 -0700 (PDT) Received: from [192.168.1.200] (p508F0FB4.dip0.t-ipconnect.de [80.143.15.180]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9D4A41C1050E3; Mon, 27 Oct 2014 21:10:41 +0100 (CET) Content-Type: text/plain; charset=windows-1256 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> Date: Mon, 27 Oct 2014 21:10:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zUlYJl8aO1aVOyF-khT21GZ6SjQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:10:48 -0000 On 27 Oct 2014, at 21:05, Christer Holmberg = wrote: > Hi, >=20 > I am not suggesting different flavors - I am suggesting to make the = usage of interleaving optional. Other SCTP features are also optional = (including reliability, ordering etc). Where are these things optional? According to = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.1 an implementation MUST implement PR-SCTP and the support of the = FORWARD-TSN chunk will be negotiated similar to the NDATA chunk. I don't see a = difference, especially not if we move to MUST support NDATA. Best regards Michael >=20 > We CAN write/reference guidelines on when it DOES make sense to use = interleaving. >=20 > Regards, >=20 > Christer >=20 > Sent from my Windows Phone > From: Michael Tuexen > Sent: =FD27/=FD10/=FD2014 21:55 > To: Christer Holmberg > Cc: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving >=20 > On 27 Oct 2014, at 19:41, Christer Holmberg = wrote: >=20 > > Hi, > >=20 > >>>>> Within the CLUE WG, we had a discussion regarding the following = statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: > >>>>>=20 > >>>>> "The support for message interleaving as defined in > >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." > >>>>>=20 > >>>>> First, it is a little unclear what "the support SHOULD be used" = means. > >>>> My understanding is that SCTP implementations supporting the = extension will use it. > >>>> This is negotiated during the setup of the SCTP association. > >>> If it's done on SCTP level, why do we need to talk about it in the = data channel draft?=20 > >>>=20 > >>> Is there a reason why it is important to use it for data channels? = If so, does it apply to data channels in general?=20 > >>=20 > >> NDATA was added in order to avoid head-of-line blocking on the = transport (if I understand this correctly, until=20 > >> this was added, sending a huge message would block the delivery of = small messages on all channels until the huge message was fully = delivered). > >>=20 > >> Unlike Michael, I see no reason to make this a SHOULD; I think it = should be a MUST, and the older=20 > >> implementations in browsers should just be called out as = non-conformant. > >>=20 > >> That said, I think that data channels ought to interoperate = successfully with implementations that don't support the=20 > >> extension - but data channel implementations in WebRTC endpoints = should be under a "MUST implement, MUST offer" ruleset. > >=20 > > First, keep in mind that I am NOT talking about WebRTC endpoints = (which is one reason we shouldn't call it webrtc data channel to begin = with, but that's another story...), but ANY type of endpoint that wants = to use a data channel.=20 > >=20 > > Second, I am not talking about MUST support, but MUST use/offer. > >=20 > > Assume I have a CLUE endpoint, which will use a data channel ONLY to = transport CLUE messages. CLUE messages aren't that hugeto begin with, = and there will be no blocking of small messages on other channels - as = there are no other channels. > >=20 > > So, why does the CLUE endpoint need to offer interleaving? > As far as I know we don't have different flavours of data channels. At = least right now. >=20 > Best regards > Michael > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >> Whether messages are interleaved or not depends on the stream = scheduler. This is a sender side only decision. The receiver has to deal = with it. > >> It is not a MUST, since there are implementations now in use which = don't support the extension. > >>=20 > >> Best regards > >> Michael > >>>=20 > >>> Second, does it mean that any data channel protocol (e.g CLUE) = SHOULD use interleaving, even if the characteristics of the protocol = wouldn't require it? > >>>=20 > >>> Regards, > >>>=20 > >>> Christer > >>> _______________________________________________ > >>> 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 > >=20 > > -- > > Surveillance is pervasive. Go Dark. > >=20 > > _______________________________________________ > > 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 nobody Mon Oct 27 13:11:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2381B1AD40B for ; Mon, 27 Oct 2014 13:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmFYHFgzHd_m for ; Mon, 27 Oct 2014 13:10:49 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15171AD40A for ; Mon, 27 Oct 2014 13:10:48 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-bc-544ea6c7e570 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.BC.24955.7C6AE445; Mon, 27 Oct 2014 21:10:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 21:10:46 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3////5gA///tr8CAAFjuAP//7KkQgAAunYCAABOJKw== Date: Mon, 27 Oct 2014 20:10:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <544EA473.6040700@alvestrand.no> In-Reply-To: <544EA473.6040700@alvestrand.no> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4CEBEDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7xZX4hBu+XCFgc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4sbmTreC7a8Xl3xENjNutuhg5OSQETCTu HJ/JDGGLSVy4t56ti5GLQ0jgCKPElFU9jBDOEkaJe08b2LsYOTjYBCwkuv9pgzSICARL9D5/ zwhiCws4SJzdOYkdIu4o0fb2PBOEHSYxs7eHFcRmEVCV+Pt9OVgNr4CvxI6X91kh5l9hkvj9 /itYEaeArsS8Dx/BhjICXfT91BqwQcwC4hJNX1ayQlwqILFkz3moq0UlXj7+xwpRky/R/fEk 1AJBiZMzn7BMYBSehaR9FpKyWUjKIOIGEl/e34aytSWWLXzNDGHrS3S/P82ELL6AkX0Vo2hx anFSbrqRsV5qUWZycXF+nl5easkmRmD8HNzyW3UH4+U3jocYBTgYlXh4P9T4hgixJpYVV+Ye YpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaRPA3ByUt8NwsxxZ2pq0k4 tirk0JGMLQtO3tE/UbXg08PZCuLXKvY7XI5yj94bmm/Z6/25f6r4qokx63pdJ0d8SX6mx5fS YW7JZHaPcdn3zpIzcndzsnrkhRsFDlUVWjRKr172fg3rjq8anqd3RtzsqXn6cmn/92qPJaca V3H87Qp+z5RSXqDEUpyRaKjFXFScCABI59PHgAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ETDY4-W7uahdOlKth9dMo--d2IA Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:10:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4CEBEDESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, We shall not add burden just because there are bad programmers out there - = they will anyway always manage to use our specs in a wrong way :) Regards, Christer Sent from my Windows Phone ________________________________ From: Harald Alvestrand Sent: =FD27/=FD10/=FD2014 22:00 To: Christer Holmberg; rtcweb@ietf.o= rg Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving On 10/27/2014 11:41 AM, Christer Holmberg wrote: > Hi, > >>>>> Within the CLUE WG, we had a discussion regarding the following state= ment in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>>> >>>>> "The support for message interleaving as defined in >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>>> >>>>> First, it is a little unclear what "the support SHOULD be used" means= . >>>> My understanding is that SCTP implementations supporting the extension= will use it. >>>> This is negotiated during the setup of the SCTP association. >>> If it's done on SCTP level, why do we need to talk about it in the data= channel draft? >>> >>> Is there a reason why it is important to use it for data channels? If s= o, does it apply to data channels in general? >> NDATA was added in order to avoid head-of-line blocking on the transport= (if I understand this correctly, until >> this was added, sending a huge message would block the delivery of small= messages on all channels until the huge message was fully delivered). >> >> Unlike Michael, I see no reason to make this a SHOULD; I think it should= be a MUST, and the older >> implementations in browsers should just be called out as non-conformant. >> >> That said, I think that data channels ought to interoperate successfully= with implementations that don't support the >> extension - but data channel implementations in WebRTC endpoints should = be under a "MUST implement, MUST offer" ruleset. > First, keep in mind that I am NOT talking about WebRTC endpoints (which i= s one reason we shouldn't call it webrtc data channel to begin with, but th= at's another story...), but ANY type of endpoint that wants to use a data c= hannel. I'm a bit self-centric on behalf of WebRTC, but I feel the other way - that it might have been a mistake to float the option of saying "other things can use these features", and that we should admit only arguments that bear upon their usage in WebRTC. I'm not sure I have WG consensus (even rough consensus) on this point, however. > > Second, I am not talking about MUST support, but MUST use/offer. > > Assume I have a CLUE endpoint, which will use a data channel ONLY to tran= sport CLUE messages. CLUE messages aren't that hugeto begin with, and there= will be no blocking of small messages on other channels - as there are no = other channels. > > So, why does the CLUE endpoint need to offer interleaving? Flipping the question around - if a programming mistake in the Javascript implementing a CLUE endpoint in a WebRTC browser happens to send a multimegabyte-sized object down the (out of order) datachannel, is it OK to have all the subsequent CLUE messages delivered 30 seconds late= ? -- Surveillance is pervasive. Go Dark. --_000_7594FB04B1934943A5C02806D1A2204B1D4CEBEDESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

We shall not add burden just because there are bad programmers out there - = they will anyway always manage to use our specs in a wrong way :)

Regards,

Christer

Sent from my Windows Phone
From: Harald Alvestrand
Sent: =FD27= /=FD10/=FD2014 22:00
To: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [= rtcweb] Meaning of SHOULD support/use interleaving

On 10/27/2014 11:41 AM, Christer Holmberg wrote: > Hi,
>
>>>>> Within the CLUE WG, we had a discussion regarding the = following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt= :
>>>>> 
>>>>> "The support for message interleaving as defined = in
>>>>>         &= nbsp;       [I-D.ietf-tsvwg-sctp-ndata] SHOUL= D be used."
>>>>> 
>>>>> First, it is a little unclear what "the support S= HOULD be used" means.
>>>> My understanding is that SCTP implementations supporting t= he extension will use it.
>>>> This is negotiated during the setup of the SCTP associatio= n.
>>> If it's done on SCTP level, why do we need to talk about it in= the data channel draft?
>>>
>>> Is there a reason why it is important to use it for data chann= els? If so, does it apply to data channels in general?
>> NDATA was added in order to avoid head-of-line blocking on the tra= nsport (if I understand this correctly, until
>> this was added, sending a huge message would block the delivery of= small messages on all channels until the huge message was fully delivered)= .
>>
>> Unlike Michael, I see no reason to make this a SHOULD; I think it = should be a MUST, and the older
>> implementations in browsers should just be called out as non-confo= rmant.
>>
>> That said, I think that data channels ought to interoperate succes= sfully with implementations that don't support the
>> extension - but data channel implementations in WebRTC endpoints s= hould be under a "MUST implement, MUST offer" ruleset.
> First, keep in mind that I am NOT talking about WebRTC endpoints (whic= h is one reason we shouldn't call it webrtc data channel to begin with, but= that's another story...), but ANY type of endpoint that wants to use a dat= a channel.

I'm a bit self-centric on behalf of WebRTC, but I feel the other way -
that it might have been a mistake to float the option of saying "other=
things can use these features", and that we should admit only argument= s
that bear upon their usage in WebRTC.

I'm not sure I have WG consensus (even rough consensus) on this point,
however.
>
> Second, I am not talking about MUST support, but MUST use/offer.
>
> Assume I have a CLUE endpoint, which will use a data channel ONLY to t= ransport CLUE messages. CLUE messages aren't that hugeto begin with, and th= ere will be no blocking of small messages on other channels - as there are = no other channels.
>
> So, why does the CLUE endpoint need to offer interleaving?

Flipping the question around - if a programming mistake in the
Javascript implementing a CLUE endpoint in a WebRTC browser happens to
send a multimegabyte-sized object down the (out of order) datachannel,
is it OK to have all the subsequent CLUE messages delivered 30 seconds late= ?



--
Surveillance is pervasive. Go Dark.


 --_000_7594FB04B1934943A5C02806D1A2204B1D4CEBEDESESSMB209erics_-- From nobody Mon Oct 27 13:32:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C971AD47D for ; Mon, 27 Oct 2014 13:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIpxTcZ1SkfJ for ; Mon, 27 Oct 2014 13:31:37 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F391AD471 for ; Mon, 27 Oct 2014 13:31:28 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id D3C05320D8B5; Mon, 27 Oct 2014 20:31:24 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9RKVRcU024764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 16:31:27 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 16:31:27 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: AQHP8e/nIllG4P1iiEigF/2tAwwrVZxEXbhogABFpgD//76eMA== Date: Mon, 27 Oct 2014 20:31:26 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5F2ED0US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/On6zd4LsMf0y1kbPGmWx_hw3K3I Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:31:40 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5F2ED0US70UWXCHMBA02z_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable +1 to make N-DATA optional. Data channel provides a robust generic peer to peer communication channel. = So, one can see that data channel may be used under non-webrtc contexts (li= ke as in CLUE) as a general transport or as a replacement of native to SCTP= to traverse firewalls. IMHO, majority of these use cases: a. May just involve a single data channel (with possible multiplexing on to= p of it) b. And may not use the DCEP either (both ends could assume same data channe= l stream id, this is similar to SCTP PPIDs). We already made DCEP(b) as optional. If an app is using just a single data channel then there is no real benefit= in using N-DATA. Then why not make it optional? Also, as already pointed o= ut, making it optional won=92t break interop as it is still negotiated duri= ng SCTP setup time anyway. I would like to point out that there will be some webrtc applications which= might just use one webrtc data channel for simplicity (and may use some mu= ltiplexing of different types of msgs/objects on top of it) or one is just = sufficient as the app does not send/recv huge chunks of data. So, N-DATA is= n=92t needed for such webrtc clients either. Then why add burden to such we= brtc implementations!? BR Raju From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Monday, October 27, 2014 3:11 PM To: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving Hi, We shall not add burden just because there are bad programmers out there - = they will anyway always manage to use our specs in a wrong way :) Regards, Christer Sent from my Windows Phone ________________________________ From: Harald Alvestrand Sent: =FD27/=FD10/=FD2014 22:00 To: Christer Holmberg; rtcweb@ietf.o= rg Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving On 10/27/2014 11:41 AM, Christer Holmberg wrote: > Hi, > >>>>> Within the CLUE WG, we had a discussion regarding the following state= ment in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>>> >>>>> "The support for message interleaving as defined in >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>>> >>>>> First, it is a little unclear what "the support SHOULD be used" means= . >>>> My understanding is that SCTP implementations supporting the extension= will use it. >>>> This is negotiated during the setup of the SCTP association. >>> If it's done on SCTP level, why do we need to talk about it in the data= channel draft? >>> >>> Is there a reason why it is important to use it for data channels? If s= o, does it apply to data channels in general? >> NDATA was added in order to avoid head-of-line blocking on the transport= (if I understand this correctly, until >> this was added, sending a huge message would block the delivery of small= messages on all channels until the huge message was fully delivered). >> >> Unlike Michael, I see no reason to make this a SHOULD; I think it should= be a MUST, and the older >> implementations in browsers should just be called out as non-conformant. >> >> That said, I think that data channels ought to interoperate successfully= with implementations that don't support the >> extension - but data channel implementations in WebRTC endpoints should = be under a "MUST implement, MUST offer" ruleset. > First, keep in mind that I am NOT talking about WebRTC endpoints (which i= s one reason we shouldn't call it webrtc data channel to begin with, but th= at's another story...), but ANY type of endpoint that wants to use a data c= hannel. I'm a bit self-centric on behalf of WebRTC, but I feel the other way - that it might have been a mistake to float the option of saying "other things can use these features", and that we should admit only arguments that bear upon their usage in WebRTC. I'm not sure I have WG consensus (even rough consensus) on this point, however. > > Second, I am not talking about MUST support, but MUST use/offer. > > Assume I have a CLUE endpoint, which will use a data channel ONLY to tran= sport CLUE messages. CLUE messages aren't that hugeto begin with, and there= will be no blocking of small messages on other channels - as there are no = other channels. > > So, why does the CLUE endpoint need to offer interleaving? Flipping the question around - if a programming mistake in the Javascript implementing a CLUE endpoint in a WebRTC browser happens to send a multimegabyte-sized object down the (out of order) datachannel, is it OK to have all the subsequent CLUE messages delivered 30 seconds late= ? -- Surveillance is pervasive. Go Dark. --_000_E1FE4C082A89A246A11D7F32A95A17828E5F2ED0US70UWXCHMBA02z_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

+1 to make N-DATA opt= ional.

 <= /p>

Data channel provides a r= obust generic peer to peer communication channel. So, one can see that data= channel may be used under non-webrtc contexts (like as in CLUE) as a general transport or as a replacement of native to SCTP to t= raverse firewalls. IMHO, majority of these use cases:

a. May just involve a sin= gle data channel (with possible multiplexing on top of it)

b. And may not use the DC= EP either (both ends could assume same data channel stream id, this is simi= lar to SCTP PPIDs).

We already made DCEP(b) a= s optional.

 <= /p>

If an app is using just a= single data channel then there is no real benefit in using N-DATA. Then wh= y not make it optional? Also, as already pointed out, making it optional won=92t break interop as it is still negotiated during SCTP se= tup time anyway.

 <= /p>

I would like to point out= that there will be some webrtc applications which might just use one webrt= c data channel for simplicity (and may use some multiplexing of different types of msgs/objects on top of it) or one is just sufficient= as the app does not send/recv huge chunks of data. So, N-DATA isn=92t need= ed for such webrtc clients either. Then why add burden to such webrtc imple= mentations!?

 <= /p>

BR

Raju

 <= /p>

 <= /p>

From: rtcweb [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, October 27, 2014 3:11 PM
To: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

 

Hi,

We shall not add burden just because there are bad programmers out there - = they will anyway always manage to use our specs in a wrong way :)

Regards,

Christer

Sent from my Windows Phone

From: Harald Alve= strand
Sent: =FD27/=FD10/=FD2014 22:00
To: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

On 10/27/2014 11:41 AM, Christer Holmberg wrote:
> Hi,
>
>>>>> Within the CLUE WG, we had a discussion regarding the = following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt= :
>>>>> 
>>>>> "The support for message interleaving as defined = in
>>>>>         &= nbsp;       [I-D.ietf-tsvwg-sctp-ndata] SHOUL= D be used."
>>>>> 
>>>>> First, it is a little unclear what "the support S= HOULD be used" means.
>>>> My understanding is that SCTP implementations supporting t= he extension will use it.
>>>> This is negotiated during the setup of the SCTP associatio= n.
>>> If it's done on SCTP level, why do we need to talk about it in= the data channel draft?
>>>
>>> Is there a reason why it is important to use it for data chann= els? If so, does it apply to data channels in general?
>> NDATA was added in order to avoid head-of-line blocking on the tra= nsport (if I understand this correctly, until
>> this was added, sending a huge message would block the delivery of= small messages on all channels until the huge message was fully delivered)= .
>>
>> Unlike Michael, I see no reason to make this a SHOULD; I think it = should be a MUST, and the older
>> implementations in browsers should just be called out as non-confo= rmant.
>>
>> That said, I think that data channels ought to interoperate succes= sfully with implementations that don't support the
>> extension - but data channel implementations in WebRTC endpoints s= hould be under a "MUST implement, MUST offer" ruleset.
> First, keep in mind that I am NOT talking about WebRTC endpoints (whic= h is one reason we shouldn't call it webrtc data channel to begin with, but= that's another story...), but ANY type of endpoint that wants to use a dat= a channel.

I'm a bit self-centric on behalf of WebRTC, but I feel the other way -
that it might have been a mistake to float the option of saying "other=
things can use these features", and that we should admit only argument= s
that bear upon their usage in WebRTC.

I'm not sure I have WG consensus (even rough consensus) on this point,
however.
>
> Second, I am not talking about MUST support, but MUST use/offer.
>
> Assume I have a CLUE endpoint, which will use a data channel ONLY to t= ransport CLUE messages. CLUE messages aren't that hugeto begin with, and th= ere will be no blocking of small messages on other channels - as there are = no other channels.
>
> So, why does the CLUE endpoint need to offer interleaving?

Flipping the question around - if a programming mistake in the
Javascript implementing a CLUE endpoint in a WebRTC browser happens to
send a multimegabyte-sized object down the (out of order) datachannel,
is it OK to have all the subsequent CLUE messages delivered 30 seconds late= ?



--
Surveillance is pervasive. Go Dark.

--_000_E1FE4C082A89A246A11D7F32A95A17828E5F2ED0US70UWXCHMBA02z_-- From nobody Mon Oct 27 13:35:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2447E1AD4A8; Mon, 27 Oct 2014 13:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReecaVUkvKYB; Mon, 27 Oct 2014 13:34:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 037601AD49B; Mon, 27 Oct 2014 13:34:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027203446.15031.69185.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 13:34:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Da01Im79hfAorjQpMmXF2_UXFSE Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-video-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:34:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Video Processing and Codec Requirements Author : Adam Roach Filename : draft-ietf-rtcweb-video-01.txt Pages : 9 Date : 2014-10-27 Abstract: This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required, as well as video codecs and their parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-video-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 13:49:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A558B1ACE45 for ; Mon, 27 Oct 2014 13:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1PBNMJ80s80 for ; Mon, 27 Oct 2014 13:48:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC011A876E for ; Mon, 27 Oct 2014 13:48:50 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9RKmmg6054455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Oct 2014 15:48:49 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <544EAFB0.40106@nostrum.com> Date: Mon, 27 Oct 2014 15:48:48 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NWoGBokAjiiYkHZdhcDEt9dKqIE Subject: [rtcweb] Video Draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:48:52 -0000 Based on feedback from (and since) Toronto, I've put out a new version of the video draft: https://tools.ietf.org/html/draft-ietf-rtcweb-video-01 Deltas: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-01.txt Some of this is forward-leaning (e.g. the colorspace) so as to provoke a disucssion. As such, I will indicate ahead of time that some of this text still needs discussion and agreement within the working group. The areas where I have done this are clearly marked with "TODO." /a From nobody Mon Oct 27 13:58:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ACF1AD4C8; Mon, 27 Oct 2014 13:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiU-don8KuKI; Mon, 27 Oct 2014 13:57:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5C31AD4B6; Mon, 27 Oct 2014 13:57:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027205754.15064.88801.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 13:57:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SftIWB5YcQ40aMAFyexatsWiflU Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-video-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:57:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Video Processing and Codec Requirements Author : Adam Roach Filename : draft-ietf-rtcweb-video-02.txt Pages : 9 Date : 2014-10-27 Abstract: This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required, as well as video codecs and their parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-video-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 13:59:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51711AD4C8 for ; Mon, 27 Oct 2014 13:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSW73If0DD_e for ; Mon, 27 Oct 2014 13:59:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616CB1AD4C2 for ; Mon, 27 Oct 2014 13:59:22 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9RKxK38055482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Oct 2014 15:59:22 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <544EB228.9040306@nostrum.com> Date: Mon, 27 Oct 2014 15:59:20 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <544EAFB0.40106@nostrum.com> In-Reply-To: <544EAFB0.40106@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XsZqg4oyZqL4yAdNxTG539bqX9c Subject: Re: [rtcweb] Video Draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:59:30 -0000 ...and pretty much right after I sent this out, someone pointed out to me that I'd mistakenly put "H.264" in the VP8 section when I was talking about VP8. So now there's a -02 out there. It simply fixes this rather confusing typo. /a On 10/27/14 15:48, Adam Roach wrote: > Based on feedback from (and since) Toronto, I've put out a new version > of the video draft: > https://tools.ietf.org/html/draft-ietf-rtcweb-video-01 > > Deltas: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-01.txt > > Some of this is forward-leaning (e.g. the colorspace) so as to provoke > a disucssion. As such, I will indicate ahead of time that some of this > text still needs discussion and agreement within the working group. > The areas where I have done this are clearly marked with "TODO." > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Oct 27 14:20:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555FC1AD542 for ; Mon, 27 Oct 2014 14:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I98vk7u142Uu for ; Mon, 27 Oct 2014 14:19:56 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA151AD540 for ; Mon, 27 Oct 2014 14:19:51 -0700 (PDT) Received: from [192.168.1.200] (p508F2A1B.dip0.t-ipconnect.de [80.143.42.27]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7764C1C104DD5; Mon, 27 Oct 2014 22:19:49 +0100 (CET) Content-Type: text/plain; charset=windows-1255 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Mon, 27 Oct 2014 22:19:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7DCAE2C4-A587-463C-A6B4-4FC609CAA985@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/701k6OcsXBCW7l76Exl1_xCDADY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 21:19:58 -0000 On 27 Oct 2014, at 21:31, Makaraju, Maridi Raju (Raju) = wrote: > +1 to make N-DATA optional. > =20 > Data channel provides a robust generic peer to peer communication = channel. So, one can see that data channel may be used under non-webrtc = contexts (like as in CLUE) as a general transport or as a replacement of = native to SCTP to traverse firewalls. IMHO, majority of these use cases: > a. May just involve a single data channel (with possible multiplexing = on top of it) > b. And may not use the DCEP either (both ends could assume same data = channel stream id, this is similar to SCTP PPIDs). > We already made DCEP(b) as optional. > =20 > If an app is using just a single data channel then there is no real = benefit in using N-DATA. Then why not make it optional? Also, as already = pointed out, making it optional won=92t break interop as it is still = negotiated during SCTP setup time anyway. > =20 > I would like to point out that there will be some webrtc applications = which might just use one webrtc data channel for simplicity (and may use = some multiplexing of different types of msgs/objects on top of it) or = one is just sufficient as the app does not send/recv huge chunks of = data. So, N-DATA isn=92t needed for such webrtc clients either. Then why = add burden to such webrtc implementations!? Are you implementing this? I would say that adding N-DATA to an SCTP = implementation with support for Stream Reconfiguration and PR-SCTP does not increase the complexity = substantially... Best regards Michael > =20 > BR > Raju > =20 > =20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer = Holmberg > Sent: Monday, October 27, 2014 3:11 PM > To: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving > =20 > Hi, >=20 > We shall not add burden just because there are bad programmers out = there - they will anyway always manage to use our specs in a wrong way = :) >=20 > Regards, >=20 > Christer >=20 > Sent from my Windows Phone > From: Harald Alvestrand > Sent: =FD27/=FD10/=FD2014 22:00 > To: Christer Holmberg; rtcweb@ietf.org > Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving >=20 > On 10/27/2014 11:41 AM, Christer Holmberg wrote: > > Hi, > > > >>>>> Within the CLUE WG, we had a discussion regarding the following = statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: > >>>>> =20 > >>>>> "The support for message interleaving as defined in > >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." > >>>>> =20 > >>>>> First, it is a little unclear what "the support SHOULD be used" = means. > >>>> My understanding is that SCTP implementations supporting the = extension will use it. > >>>> This is negotiated during the setup of the SCTP association. > >>> If it's done on SCTP level, why do we need to talk about it in the = data channel draft?=20 > >>> > >>> Is there a reason why it is important to use it for data channels? = If so, does it apply to data channels in general?=20 > >> NDATA was added in order to avoid head-of-line blocking on the = transport (if I understand this correctly, until=20 > >> this was added, sending a huge message would block the delivery of = small messages on all channels until the huge message was fully = delivered). > >> > >> Unlike Michael, I see no reason to make this a SHOULD; I think it = should be a MUST, and the older=20 > >> implementations in browsers should just be called out as = non-conformant. > >> > >> That said, I think that data channels ought to interoperate = successfully with implementations that don't support the=20 > >> extension - but data channel implementations in WebRTC endpoints = should be under a "MUST implement, MUST offer" ruleset. > > First, keep in mind that I am NOT talking about WebRTC endpoints = (which is one reason we shouldn't call it webrtc data channel to begin = with, but that's another story...), but ANY type of endpoint that wants = to use a data channel.=20 >=20 > I'm a bit self-centric on behalf of WebRTC, but I feel the other way - > that it might have been a mistake to float the option of saying "other > things can use these features", and that we should admit only = arguments > that bear upon their usage in WebRTC. >=20 > I'm not sure I have WG consensus (even rough consensus) on this point, > however. > > > > Second, I am not talking about MUST support, but MUST use/offer. > > > > Assume I have a CLUE endpoint, which will use a data channel ONLY to = transport CLUE messages. CLUE messages aren't that hugeto begin with, = and there will be no blocking of small messages on other channels - as = there are no other channels. > > > > So, why does the CLUE endpoint need to offer interleaving? >=20 > Flipping the question around - if a programming mistake in the > Javascript implementing a CLUE endpoint in a WebRTC browser happens to > send a multimegabyte-sized object down the (out of order) datachannel, > is it OK to have all the subsequent CLUE messages delivered 30 seconds = late? >=20 >=20 >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Oct 27 15:03:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EF11A016D for ; Mon, 27 Oct 2014 15:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d8Wy2caigh4 for ; Mon, 27 Oct 2014 15:03:01 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 550E81A0123 for ; Mon, 27 Oct 2014 15:03:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 96D5D7C5B5A; Mon, 27 Oct 2014 23:03:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq1xastoO9XT; Mon, 27 Oct 2014 23:02:56 +0100 (CET) Received: from [172.26.53.1] (unknown [216.239.45.130]) by mork.alvestrand.no (Postfix) with ESMTPSA id 952417C5B41; Mon, 27 Oct 2014 23:02:54 +0100 (CET) Message-ID: <544EC109.4030600@alvestrand.no> Date: Mon, 27 Oct 2014 15:02:49 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , Christer Holmberg , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000200080709040002030806" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JnaVsd8-S0XI_VHPsKWMCM_5338 Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 22:03:10 -0000 This is a multi-part message in MIME format. --------------000200080709040002030806 Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: quoted-printable On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju) wrote: > > +1 to make N-DATA optional. > > =20 > > Data channel provides a robust generic peer to peer communication > channel. So, one can see that data channel may be used under > non-webrtc contexts (like as in CLUE) as a general transport or as a > replacement of native to SCTP to traverse firewalls. IMHO, majority of > these use cases: > > a. May just involve a single data channel (with possible multiplexing > on top of it) > > b. And may not use the DCEP either (both ends could assume same data > channel stream id, this is similar to SCTP PPIDs). > > We already made DCEP(b) as optional. > > =20 > > If an app is using just a single data channel then there is no real > benefit in using N-DATA. Then why not make it optional? Also, as > already pointed out, making it optional won=92t break interop as it is > still negotiated during SCTP setup time anyway. > Negotiation means that transport initiator gets to choose whether to use it or not. This means that a responder has no choice in the matter. In the situation where the responder knows better than the initiator what the usage is going to be, this is problematic. > =20 > > I would like to point out that there will be some webrtc applications > which might just use one webrtc data channel for simplicity (and may > use some multiplexing of different types of msgs/objects on top of it) > or one is just sufficient as the app does not send/recv huge chunks of > data. So, N-DATA isn=92t needed for such webrtc clients either. Then wh= y > add burden to such webrtc implementations!? > You're confusing the webrtc application (what runs in the browser) with the webrtc implementation (the browser itself). Optional NDATA makes the browser *more* complex, since it has to expose API surface to let the application choose whether or not to offer NDATA, and it has to have code to decide whether or not to offer NDATA. If you're arguing that we should make NDATA optional to implement for browsers ..... that is an issue that I thought we had already settled. > =20 > > BR > > Raju > > =20 > > =20 > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* Monday, October 27, 2014 3:11 PM > *To:* Harald Alvestrand; rtcweb@ietf.org > *Subject:* Re: [rtcweb] Meaning of SHOULD support/use interleaving > > =20 > > Hi, > > We shall not add burden just because there are bad programmers out > there - they will anyway always manage to use our specs in a wrong way = :) > > Regards, > > Christer > > Sent from my Windows Phone > > -----------------------------------------------------------------------= - > > *From: *Harald Alvestrand > *Sent: *=FD27/=FD10/=FD2014 22:00 > *To: *Christer Holmberg ; > rtcweb@ietf.org > *Subject: *Re: [rtcweb] Meaning of SHOULD support/use interleaving > > On 10/27/2014 11:41 AM, Christer Holmberg wrote: > > Hi, > > > >>>>> Within the CLUE WG, we had a discussion regarding the following > statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: > >>>>>=20 > >>>>> "The support for message interleaving as defined in > >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." > >>>>>=20 > >>>>> First, it is a little unclear what "the support SHOULD be used" > means. > >>>> My understanding is that SCTP implementations supporting the > extension will use it. > >>>> This is negotiated during the setup of the SCTP association. > >>> If it's done on SCTP level, why do we need to talk about it in the > data channel draft? > >>> > >>> Is there a reason why it is important to use it for data channels? > If so, does it apply to data channels in general? > >> NDATA was added in order to avoid head-of-line blocking on the > transport (if I understand this correctly, until > >> this was added, sending a huge message would block the delivery of > small messages on all channels until the huge message was fully > delivered). > >> > >> Unlike Michael, I see no reason to make this a SHOULD; I think it > should be a MUST, and the older > >> implementations in browsers should just be called out as > non-conformant. > >> > >> That said, I think that data channels ought to interoperate > successfully with implementations that don't support the > >> extension - but data channel implementations in WebRTC endpoints > should be under a "MUST implement, MUST offer" ruleset. > > First, keep in mind that I am NOT talking about WebRTC endpoints > (which is one reason we shouldn't call it webrtc data channel to begin > with, but that's another story...), but ANY type of endpoint that > wants to use a data channel. > > I'm a bit self-centric on behalf of WebRTC, but I feel the other way - > that it might have been a mistake to float the option of saying "other > things can use these features", and that we should admit only arguments= > that bear upon their usage in WebRTC. > > I'm not sure I have WG consensus (even rough consensus) on this point, > however. > > > > Second, I am not talking about MUST support, but MUST use/offer. > > > > Assume I have a CLUE endpoint, which will use a data channel ONLY to > transport CLUE messages. CLUE messages aren't that hugeto begin with, > and there will be no blocking of small messages on other channels - as > there are no other channels. > > > > So, why does the CLUE endpoint need to offer interleaving? > > Flipping the question around - if a programming mistake in the > Javascript implementing a CLUE endpoint in a WebRTC browser happens to > send a multimegabyte-sized object down the (out of order) datachannel, > is it OK to have all the subsequent CLUE messages delivered 30 seconds > late? > > > > --=20 > Surveillance is pervasive. Go Dark. > --=20 Surveillance is pervasive. Go Dark. --------------000200080709040002030806 Content-Type: text/html; charset=windows-1255 Content-Transfer-Encoding: 8bit
On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju) wrote:

+1 to make N-DATA optional.

 

Data channel provides a robust generic peer to peer communication channel. So, one can see that data channel may be used under non-webrtc contexts (like as in CLUE) as a general transport or as a replacement of native to SCTP to traverse firewalls. IMHO, majority of these use cases:

a. May just involve a single data channel (with possible multiplexing on top of it)

b. And may not use the DCEP either (both ends could assume same data channel stream id, this is similar to SCTP PPIDs).

We already made DCEP(b) as optional.

 

If an app is using just a single data channel then there is no real benefit in using N-DATA. Then why not make it optional? Also, as already pointed out, making it optional won’t break interop as it is still negotiated during SCTP setup time anyway.


Negotiation means that transport initiator gets to choose whether to use it or not.
This means that a responder has no choice in the matter.

In the situation where the responder knows better than the initiator what the usage is going to be, this is problematic.

 

I would like to point out that there will be some webrtc applications which might just use one webrtc data channel for simplicity (and may use some multiplexing of different types of msgs/objects on top of it) or one is just sufficient as the app does not send/recv huge chunks of data. So, N-DATA isn’t needed for such webrtc clients either. Then why add burden to such webrtc implementations!?


You're confusing the webrtc application (what runs in the browser) with the webrtc implementation (the browser itself). Optional NDATA makes the browser *more* complex, since it has to expose API surface to let the application choose whether or not to offer NDATA, and it has to have code to decide whether or not to offer NDATA.

If you're arguing that we should make NDATA optional to implement for browsers ..... that is an issue that I thought we had already settled.

 

BR

Raju

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, October 27, 2014 3:11 PM
To: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

 

Hi,

We shall not add burden just because there are bad programmers out there - they will anyway always manage to use our specs in a wrong way :)

Regards,

Christer

Sent from my Windows Phone

From: Harald Alvestrand
Sent: ý27/ý10/ý2014 22:00
To: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

On 10/27/2014 11:41 AM, Christer Holmberg wrote:
> Hi,
>
>>>>> Within the CLUE WG, we had a discussion regarding the following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt:
>>>>> 
>>>>> "The support for message interleaving as defined in
>>>>>                 [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used."
>>>>> 
>>>>> First, it is a little unclear what "the support SHOULD be used" means.
>>>> My understanding is that SCTP implementations supporting the extension will use it.
>>>> This is negotiated during the setup of the SCTP association.
>>> If it's done on SCTP level, why do we need to talk about it in the data channel draft?
>>>
>>> Is there a reason why it is important to use it for data channels? If so, does it apply to data channels in general?
>> NDATA was added in order to avoid head-of-line blocking on the transport (if I understand this correctly, until
>> this was added, sending a huge message would block the delivery of small messages on all channels until the huge message was fully delivered).
>>
>> Unlike Michael, I see no reason to make this a SHOULD; I think it should be a MUST, and the older
>> implementations in browsers should just be called out as non-conformant.
>>
>> That said, I think that data channels ought to interoperate successfully with implementations that don't support the
>> extension - but data channel implementations in WebRTC endpoints should be under a "MUST implement, MUST offer" ruleset.
> First, keep in mind that I am NOT talking about WebRTC endpoints (which is one reason we shouldn't call it webrtc data channel to begin with, but that's another story...), but ANY type of endpoint that wants to use a data channel.

I'm a bit self-centric on behalf of WebRTC, but I feel the other way -
that it might have been a mistake to float the option of saying "other
things can use these features", and that we should admit only arguments
that bear upon their usage in WebRTC.

I'm not sure I have WG consensus (even rough consensus) on this point,
however.
>
> Second, I am not talking about MUST support, but MUST use/offer.
>
> Assume I have a CLUE endpoint, which will use a data channel ONLY to transport CLUE messages. CLUE messages aren't that hugeto begin with, and there will be no blocking of small messages on other channels - as there are no other channels.
>
> So, why does the CLUE endpoint need to offer interleaving?

Flipping the question around - if a programming mistake in the
Javascript implementing a CLUE endpoint in a WebRTC browser happens to
send a multimegabyte-sized object down the (out of order) datachannel,
is it OK to have all the subsequent CLUE messages delivered 30 seconds late?



--
Surveillance is pervasive. Go Dark.



-- 
Surveillance is pervasive. Go Dark.
--------------000200080709040002030806-- From nobody Mon Oct 27 15:34:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473C91A1B24 for ; Mon, 27 Oct 2014 15:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhgngKW3glaL for ; Mon, 27 Oct 2014 15:33:53 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2641C1A1B23 for ; Mon, 27 Oct 2014 15:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1414449230; x=1415658830; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wCKCr85bVelJ/XTIKNKzUUhp+Tvjl6mUVmh9MRL2XDs=; b=hZdz2yR8mCwoGjyywrwBHmq9AarVPJ9YH/3vvjwPmsdRcgHieorhhtHz s+vqneiMc/B5IShaLdzJTHhLTJi1kK/209B4FjKX6hZza1bGBtl7EoA25 7W6WhQSp+q1C2cmBbsKhr6OULGDilbHxkU+yQcZBGMx0z6LMlvFsYU9r+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAGAK7HTlStJV2Q/2dsb2JhbABcgw5UWASDAspRh0sCG4EBFgFyC4QEAQQjBgtDFAECIAIGIAIEMBURAQQbAYg4DacXj0KVBgEBAQEGAQEBAQEBHIEsjyuDLzaBHgWSB4RIiEM8gw2RNIN4bAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.04,798,1406592000"; d="scan'208";a="90820892" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 27 Oct 2014 22:33:49 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9RMXnEw005598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Oct 2014 22:33:49 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.253]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 17:33:49 -0500 From: "David Benham (dbenham)" To: "rtcweb@ietf.org" Thread-Topic: Notification for draft-benham-rtcweb-vp8litigation-00.txt Thread-Index: Ac/yNg3TpVJnasOlQ/+UW41H77yHow== Importance: high X-Priority: 1 Date: Mon, 27 Oct 2014 22:33:49 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC564ECB5EA@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.140.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EqO6JrX8aOHn5kvqt0OZwge3tcw Subject: [rtcweb] Notification for draft-benham-rtcweb-vp8litigation-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 22:33:56 -0000 QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJlbmhhbS1ydGN3ZWItdnA4bGl0aWdhdGlvbi0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGF2aWQgQmVuaGFtIGFu ZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1iZW5oYW0t cnRjd2ViLXZwOGxpdGlnYXRpb24NClJldmlzaW9uOgkwMA0KVGl0bGU6CQlWUDggUmVsYXRlZCBM aXRpZ2F0aW9uIFN0YXR1cyBTbmFwc2hvdA0KRG9jdW1lbnQgZGF0ZToJMjAxNC0xMC0yNw0KR3Jv dXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJNg0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJlbmhhbS1ydGN3ZWItdnA4 bGl0aWdhdGlvbi0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1iZW5oYW0tcnRjd2ViLXZwOGxpdGlnYXRpb24vDQpIdG1saXplZDog ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVuaGFtLXJ0Y3dlYi12cDhs aXRpZ2F0aW9uLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGVyZSByZW1haW5zIGEgZ3JlYXQgZGVh bCBvZiBjb25mdXNpb24gaW4gdGhlIGluZHVzdHJ5IGFib3V0IHRoZQ0KICAgc3RhdGUgb2YgcGF0 ZW50IGxpdGlnYXRpb24gYW5kIElQUiBkaXNjbG9zdXJlcyBhcm91bmQgVlA4LiBUbw0KICAgZmFj aWxpdGF0ZSBncmVhdGVyIHVuZGVyc3RhbmRpbmcsIER1YW5lIE1vcnJpcyBMTFAgZHJhZnRlZCBh IHBhcGVyDQogICB0aGF0IHN1bW1hcml6ZXMgdGhlIGN1cnJlbnQgc3RhdGUgb2YgZGlzY2xvc3Vy ZXMgYW5kIHBhdGVudA0KICAgbGl0aWdhdGlvbiBiYXNlZCBvbiBwdWJsaWNhbGx5IGF2YWlsYWJs ZSBtYXRlcmlhbHMgYW5kIHBvc3RlZCB0aGlzDQogICBjb21wcmVoZW5zaXZlIHJlcG9ydCBvbiB0 aGUgSW50ZXJuZXQuIFRoaXMgSW50ZXJuZXQgRHJhZnQgcHJvdmlkZXMgYQ0KICAgaGlnaCBsZXZl bCBzdW1tYXJ5IG9mIHRoYXQgcmVwb3J0LiBDaXNjbyBTeXN0ZW1zIHJlcXVlc3RlZCBhbmQgZnVu ZGVkDQogICBEdWFuZSBNb3JyaXMgdG8gcHJlcGFyZSB0aGlzIHJlcG9ydC4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Oct 27 16:57:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F451A86FE for ; Mon, 27 Oct 2014 16:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFLXMonhcj1t for ; Mon, 27 Oct 2014 16:57:37 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD3B1A87A8 for ; Mon, 27 Oct 2014 16:57:22 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id va2so4365231obc.28 for ; Mon, 27 Oct 2014 16:57:22 -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 :content-type; bh=jqoxVui/XBZiTnJ650Yx0IghWcC1nfwpXIR2VYj/BS4=; b=gbaFs1hrm6Ixphc2f2BvHlVUO9njG+Xh8wFBLFBMkuVPReLOgimC99JhQplPsFy73x R4aZrnoNr8ttFBUZSYGrC++Lf0ntpOXqNwX+jE/Ya1Z/b5SeGsfJKwZ+jWfK+oh+f6xR JsfqgnYFWP8OqmAxZV5ZSizuMrqvRSiU2DtObWVAHvhH4zjrcWYXGI+av3mE7DGFMI4S 6ZPFUn1CDTQs0yTODcxBfqFsQ5wtct3RDwazvfpssGLNgTymPY9PrHEMwDxo6zvihFEY haUfzAdx/0d4QNXOi45T0sfJQfIX4YauZELnnK7SIEdOWBnNs9n+xCuepr0Bb3IzbWHD EdOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=jqoxVui/XBZiTnJ650Yx0IghWcC1nfwpXIR2VYj/BS4=; b=J2qi1GJUVKbkxk3kn/0QHcU9CTCK5vXpq9qfLyMDj00nHgysZj6WpOAD+couAmbLHl H4PqIZFmMdSplpu8i4WoHGwHoI3895VY1Mv7PSrLugoSntVkuY8ilc9PQtJbut06jM15 Sx85YIdyQgRuNnl1ASuS6PPDvWEFdCaMI6fm6Yj88xg+x6gUMHf0YBn4sclSkr7Y0GcM 2F8pkTuABdi/p7jI+/d4gQbsrYuoGPHr8qd5ZoInwDakTiexVvfzeaDsvNL5goCQZH3C DOQVT/ktUcsSNnz/wQ2lZI6ZE6nBK5IwW5VmaRVAlZAwP44Ktxjd/2AhUGDMmvPrvgML 2jLA== X-Gm-Message-State: ALoCoQmk3JWY6l4/Ex8fY8yM8gW/9wXbGbo6bj03K26XZ9ExvF0oIiWvICo5cxxGexT/0iPlF8WV X-Received: by 10.60.94.73 with SMTP id da9mr16091269oeb.10.1414454242396; Mon, 27 Oct 2014 16:57:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Mon, 27 Oct 2014 16:57:02 -0700 (PDT) In-Reply-To: References: <20141027234830.13650.48206.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Mon, 27 Oct 2014 16:57:02 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e01229176ab6cdd0506704ac2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JHQBlGyOro_qCwM52VmmuzWz91o Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-fec-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 23:57:39 -0000 --089e01229176ab6cdd0506704ac2 Content-Type: text/plain; charset=UTF-8 An initial version of FEC requirements for WebRTC. I'd like to get some agenda time to discuss this in Honolulu. ---------- Forwarded message ---------- From: Date: Mon, Oct 27, 2014 at 4:48 PM Subject: New Version Notification for draft-uberti-rtcweb-fec-00.txt To: Justin Uberti A new version of I-D, draft-uberti-rtcweb-fec-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Name: draft-uberti-rtcweb-fec Revision: 00 Title: WebRTC Forward Error Correction Requirements Document date: 2014-10-27 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-fec-00.txt Status: https://datatracker.ietf.org/doc/draft-uberti-rtcweb-fec/ Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-fec-00 Abstract: This document makes recommendations for how Forward Error Correction (FEC) should be used by WebRTC applications. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e01229176ab6cdd0506704ac2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
An initial version of FEC requi= rements for WebRTC. I'd like to get some agenda time to discuss this in= Honolulu.

---------- Fo= rwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Oct 27, 2014 at = 4:48 PM
Subject: New Version Notification for draft-uberti-rtcweb-fec-00= .txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-fec-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-rtcweb-fec
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WebRTC Forward Error Correction Re= quirements
Document date:=C2=A0 2014-10-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://= www.ietf.org/internet-drafts/draft-uberti-rtcweb-fec-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.i= etf.org/doc/draft-uberti-rtcweb-fec/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/dra= ft-uberti-rtcweb-fec-00


Abstract:
=C2=A0 =C2=A0This document makes recommendations for how Forward Error Corr= ection
=C2=A0 =C2=A0(FEC) should be used by WebRTC applications.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--089e01229176ab6cdd0506704ac2-- From nobody Mon Oct 27 17:15:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815691A86F7 for ; Mon, 27 Oct 2014 17:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBXPgbLXvLvb for ; Mon, 27 Oct 2014 17:15:40 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C031A8547 for ; Mon, 27 Oct 2014 17:15:39 -0700 (PDT) Received: from [10.252.26.205] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D1156F232C for ; Mon, 27 Oct 2014 17:15:38 -0700 (PDT) Message-ID: <544EE02A.5050802@mozilla.com> Date: Mon, 27 Oct 2014 17:15:38 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <0683D6CB32AC424D8AF52C0F660E5DC564ECB5EA@xmb-aln-x10.cisco.com> In-Reply-To: <0683D6CB32AC424D8AF52C0F660E5DC564ECB5EA@xmb-aln-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lhZ1368KCnVuYF3qqFu8As-CUmU Subject: Re: [rtcweb] Notification for draft-benham-rtcweb-vp8litigation-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 00:15:43 -0000 David Benham (dbenham) wrote: > There remains a great deal of confusion in the industry about the > state of patent litigation and IPR disclosures around VP8. To Thanks for compiling this report, David. Hopefully this can avoid wasting time on arguments about what should be publicly documented facts. I just wanted to comment that your use of the acronym "FRAND" to mean "Free under Reasonable And Non-Discriminatory" terms may lead to some confusion, as there is already an existing expansion in common use, namely "Fair, Reasonable, And Non-Discriminatory". The term doesn't appear in the Duane Morris report you cite (except in a citation, where I believe it is intended to refer to the latter expansion, not the former). I've been looking for a good term to use for technology which is covered by patents, but for which royalty-free licenses with open-source compatible terms exist. "Royalty-Free" doesn't quite fit the bill, as there are examples of royalty-free licenses which would preclude an open-source implementation [1]. "Patent-free" is clearly wrong and "patent-unencumbered", while better, might still be misleading (however, it's the best I've been able to think of). If someone can think of a better way to describe this class of licenses, I am all ears. RFLWOSCT doesn't quite roll off the tongue. [1] Clause 2.5 (among others) of http://www.polycom.com/content/dam/polycom/www/documents/program-details/siren-license-agreement.pdf being one example. From nobody Mon Oct 27 17:18:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0553D1A87AC for ; Mon, 27 Oct 2014 17:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sxOVTJZp7ou for ; Mon, 27 Oct 2014 17:18:28 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359281A879A for ; Mon, 27 Oct 2014 17:18:28 -0700 (PDT) Received: by mail-oi0-f45.google.com with SMTP id i138so4312444oig.32 for ; Mon, 27 Oct 2014 17:18:27 -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; bh=QsvWwJzcNU0uml4HLl0051MObRPDkAXiLeQwuFUDmQE=; b=ORKn1Bf9a3FXq3++kAzIDNfR/MpdLL9OTI3ba/mI0+SNa6EIRhYyK2tFvUYmgM1Est JWHre5aOqpVftpW+JqLusr7VJA33C1j6b2c6r504PueUqpj5NcYwbigjn9UTjXDWBYNv J6sG7htJgWRq0T1HWdhwXeploNATPYfIWCeTGf8nvoPKw+y/E7VxecmxLePiyjDPMMmi Drfb+Khpbs6m6eT5Gf6hw2pnnbFszmxemUKKc1BdgJ35DgzfU73JRri3RvZWR5onTtrb 6mECIYzX/1BNjVSUFhQqXSAkUgrWEhixwR1BF2xoOLsChAlCCICKigWEE80glxvTIHBG KnYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QsvWwJzcNU0uml4HLl0051MObRPDkAXiLeQwuFUDmQE=; b=etn74nVn5t8fDOLAwEiJPMeeamk0O76hOH+ldPiFPoqImhIh2ANwU6LW4/Hj/tJwfx XeLhN5cyvsYRge+9HEzxbS6sljSbhPKLTqRPG2ECPo8f6IcwUzSScnwkPqFwotYGMR5D WwA4y9TZrLWqHwjrBQ0FZY9l1pxasMJ5AeRyRVs0i6E4KSOeWniPJXXdThuu78sGO5w6 npcc2ANqbmRU3tFgDQz4BBVSpKubngCBl1BKZ12rbjWErZCZ1p3Bl32kH8svOsyhTDCU ltjOL2bX+uM/UeGTgOx8WwFPCRlDjytGWB/8QU+P/y65u+0+IPYWmAqFADuaOJocRAu3 PHRQ== X-Gm-Message-State: ALoCoQlXjH/hhv2tthx5SG0suE54a6MMlwwIj0jxMC/hURIitDOuhRnEpDwadMzXTT1xggqLUfUk X-Received: by 10.60.67.165 with SMTP id o5mr23371662oet.24.1414455507524; Mon, 27 Oct 2014 17:18:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Mon, 27 Oct 2014 17:18:07 -0700 (PDT) In-Reply-To: <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> <544E7E2B.6040809@gmail.com> <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> From: Justin Uberti Date: Mon, 27 Oct 2014 17:18:07 -0700 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=001a11c31dd813c1f705067096a8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dXibemZ7u8vxKeIVqdXm8UFL66o Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 00:18:30 -0000 --001a11c31dd813c1f705067096a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins wrote: > On 27 Oct 2014, at 17:17, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > On 27/10/2014 18:10, Colin Perkins wrote: > > On 27 Oct 2014, at 16:51, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > On 27/10/2014 17:45, Colin Perkins wrote: > > On 27 Oct 2014, at 16:40, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > On 27/10/2014 17:36, Colin Perkins wrote: > > On 21 Oct 2014, at 19:58, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > Not sure if it is done on pourpose, but according to the RTP usage draft, > it may seem that full RFC 4588 is mandated at the recevier side: > > Receivers are REQUIRED to implement support for RTP retransmission > packets [RFC4588 ]. > > > That would include both modes, session and ssrc multiplexing. Given the > extensive usage of bundle and current implementations, session multiplexi= ng > support doesn't make much sense. > > Should we drop it, and state that only ssrc-multiplexing shall be > supported at the receiving end? > > > I don=E2=80=99t see any advantage to doing so, given that support for no= n-BUNDLE > sessions is REQUIRED. You need to implement the signalling needed for > session-multiplexing of retransmission packet anyway, so disallowing it > buys you nothing. > > > You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I > don't see is how to do session multiplexing with BUNDLE sessions. > > > You can=E2=80=99t do session multiplexing for BUNDLE sessions; by defini= tion > they use SSRC multiplexing. You could do non-BUNDLE sessions, with > retransmission sent on a separate RTP session though. > > So, you are saying exactly the same than me. SSRC multiplexing supports > both BUNDLE and NON-BUNDLE. So, why require support for session > multiplexing at all? As a developer, I don't see why I would have to > implement something that would be rarely used and provide no extra benefi= t. > > > Non-BUNDLE is session multiplexing. It uses a separate RTP session for > the retransmissions. > > Maybe I am the missing something, if you don't use bundle to send the > audio/video on same rtpsession, you can still send rtx+video on same > session. That's it non-bundle with ssrc-multiplexing. Are we referring to > different things? > > > Sure, but that doesn=E2=80=99t alter the fact that the group decided that > non-BUNDLE media needs to be supported. Sending retransmission on a > separate RTP session is as needed for interoperability with legacy system= s > as sending audio and video on separate RTP sessions (and shouldn=E2=80=99= t be hard > to support, since it uses the same mechanisms). > > Non-BUNDLE media needs to be supported, but I don't think the WG ever explicitly signed up for session-multiplexing of RTX data. Unified plan is quite clear in its assertion that the primary, RTX, and FEC flows for a given media stream should all be represented by a single m=3D line, e.g. SSRC-multiplexed. --001a11c31dd813c1f705067096a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins <<= a href=3D"mailto:csp@csperkins.org" target=3D"_blank">csp@csperkins.org= > wrote:
On 27 Oct 2014, at 17:17, Sergio Garcia Muri= llo <sergio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
On 27/10/2014 18:10, Colin Perkins wrote:
=20 On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@g= mail.com> wrote:
=20
On 27/10/2014 17:45, Colin Perkins wrote:
=20 On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia= .murillo@gmail.com> wrote:
=20
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement =
support for RTP retransmission
   =C2=A0packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don=E2=80=99t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=E2=80=99t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE is session multiplexing. It uses a separate RTP session for the retransmissions.
Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different things?

=
Sure, but that doesn=E2=80=99t alter the fact that the group decided t= hat non-BUNDLE media needs to be supported. Sending retransmission on a sep= arate RTP session is as needed for interoperability with legacy systems as = sending audio and video on separate RTP sessions (and shouldn=E2=80=99t be = hard to support, since it uses the same mechanisms).

--001a11c31dd813c1f705067096a8-- From nobody Mon Oct 27 17:25:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E071A87CE for ; Mon, 27 Oct 2014 17:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ExlPMjEttUu for ; Mon, 27 Oct 2014 17:25:51 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D4A1A87C9 for ; Mon, 27 Oct 2014 17:25:51 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so6557490lbv.7 for ; Mon, 27 Oct 2014 17:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VkJOF5VwVsmV7KOF7/MWCazKzIAoGHZbcluAGgZNwh0=; b=koxOvGNrIu1gT0YWmj10A9XdAcOFJfrMGNwaj3yD4ELGh7Px3OsDXAHO3Y1n1vQn3W VobIKe421WiyJCo8iXJeVQdwZa+TZgr0f8nsTUhoOGcszL1mSUEHwK+r3j8sL4xcfHEu sNayV1IRBNJiiNzmtwttI99Mw1XPtHaEkepixRClNIUwtJOKRv7iSaYPkgGRc1xCIuro 1uIKQ8jGYyqG/5N+eKINz7xB8VawZ/8ANxpvGE+1nG0qTzTIeVl/BIYQEV1k1GbOm7yj MCcoSKcsn531wyUMcM4TZiUUfnOoLoOHmGKm3Ra6YBjZOd6D7dyGueu3+kMtjmhI4uG7 JHlw== MIME-Version: 1.0 X-Received: by 10.152.20.72 with SMTP id l8mr20041908lae.43.1414455949825; Mon, 27 Oct 2014 17:25:49 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Mon, 27 Oct 2014 17:25:49 -0700 (PDT) In-Reply-To: <544EC109.4030600@alvestrand.no> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> <544EC109.4030600@alvestrand.no> Date: Mon, 27 Oct 2014 17:25:49 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zMxQDT6zdB_6CORxmv4yv62yx9I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 00:25:53 -0000 On 27 October 2014 15:02, Harald Alvestrand wrote: > You're confusing the webrtc application (what runs in the browser) with the > webrtc implementation (the browser itself). Optional NDATA makes the browser > *more* complex, since it has to expose API surface to let the application > choose whether or not to offer NDATA, and it has to have code to decide > whether or not to offer NDATA. Yes. I don't understand why we would want to say no to making NDATA mandatory for browsers, other than to note that not all peers will support NDATA. SCTP without NDATA simply isn't fit for purpose. From nobody Mon Oct 27 17:30:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FF51A0358 for ; Mon, 27 Oct 2014 17:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2Zbh6_24Dur for ; Mon, 27 Oct 2014 17:30:08 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1F81A02BE for ; Mon, 27 Oct 2014 17:30:07 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id z12so4419573wgg.9 for ; Mon, 27 Oct 2014 17:30:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=78ieX0Hzaf26+DjDCOtVCjEP22B2ROOGD+sv8D+wp+I=; b=hO3ZiIluGlU1DhPJcWRhrOXdWMV7e0i0EIA7BO3o2ghUCLJxj4zMcKUvPUP3CNfT+w upgd4mWzI6KTykdszNdoMlfRjOcUXXEXIk9OYELCLykv7vUQtL7xyOxb2QEglE/To8B2 i0CXWPk7xgZHtOIjLNdKf2SnJuimnv5UF3WOoiZtJbo5BZ1YLd0ygzBsujr/tTEkaRSr vpuHwk512Eoa4jwZpM3fiCx9m/k2KwKFGhReVSvahCHyXJvwkptiTtTmH9YfBHYmzcfQ +6zoVD554LSwucclYbLA4/7+qZ6dDEWl9Y0BkABhAZgYIESnpRp1fjXQSq6wkIETIi3a mvMg== X-Gm-Message-State: ALoCoQm/18Ry3/R6WdKbFfMNnLMn2yokUg+hCB81gtq5f0x0w4l0z27xFPXJiqUgXFj3QtHGXaxP X-Received: by 10.194.242.4 with SMTP id wm4mr3254582wjc.61.1414456206782; Mon, 27 Oct 2014 17:30:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Mon, 27 Oct 2014 17:29:26 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> <544EC109.4030600@alvestrand.no> From: Eric Rescorla Date: Mon, 27 Oct 2014 17:29:26 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01419af6c183c0050670bf17 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wHFVy2d7vjdwxNs-fVzepXyACTU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 00:30:10 -0000 --089e01419af6c183c0050670bf17 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 27, 2014 at 5:25 PM, Martin Thomson wrote: > On 27 October 2014 15:02, Harald Alvestrand wrote: > > You're confusing the webrtc application (what runs in the browser) with > the > > webrtc implementation (the browser itself). Optional NDATA makes the > browser > > *more* complex, since it has to expose API surface to let the application > > choose whether or not to offer NDATA, and it has to have code to decide > > whether or not to offer NDATA. > > > Yes. I don't understand why we would want to say no to making NDATA > mandatory for browsers, other than to note that not all peers will > support NDATA. > I agree with this. Let's require what we need. -Ekr SCTP without NDATA simply isn't fit for purpose. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e01419af6c183c0050670bf17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 27, 2014 at 5:25 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 27 October 2014 15:02, Harald Alvestrand <harald@alvestrand.no> wrote:
> You're confusing the webrtc application (what runs in the browser)= with the
> webrtc implementation (the browser itself). Optional NDATA makes the b= rowser
> *more* complex, since it has to expose API surface to let the applicat= ion
> choose whether or not to offer NDATA, and it has to have code to decid= e
> whether or not to offer NDATA.


Yes.=C2=A0 I don't understand why we would want to say no to mak= ing NDATA
mandatory for browsers, other than to note that not all peers will
support NDATA.

I agree with this. Let&#= 39;s require what we need.

-Ekr

SCTP without NDATA simply isn't fit for purpose.

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

--089e01419af6c183c0050670bf17-- From nobody Mon Oct 27 17:39:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFD41A0360 for ; Mon, 27 Oct 2014 17:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JedOsS4TdLwj for ; Mon, 27 Oct 2014 17:39:32 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443E61A02BE for ; Mon, 27 Oct 2014 17:39:32 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id e131so1615632oig.14 for ; Mon, 27 Oct 2014 17:39:31 -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; bh=6lx38xQ1sfs0cOymsPOHUp6Z433C+8EfFmYdS4Uv0rA=; b=Mx6Tp/R4hLshAv0cra7yrfI/vzhFTpNdD0TPIDIVG3zSY95hKF4lPWCfXvMbVVsosC w5wnWk5cd4u3eIz7B/e+Ww16Ckwd6H2MEg8iRxmXvb6mFGE3trzGbuxkZNNad3L0gG8G 3WyQMw8XH2yX290/XT5tun8bo4DsQEStpECzNBVoDGRLuX46qGhhx0sLJvQErYaVJpf/ dNdZIa8Z1obRjGF67KbaG5P2f6UaLdTRu9Y2pz2rBHZxi/4tKQyQXqkEymYWDZ/qcwgb DKBlNmNLcJgnlwqSBcXGtwQfJMxnAPVAJ75nC9mo4C8d6rrfGixzxfAC0Y14wEEqbb4x A3Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6lx38xQ1sfs0cOymsPOHUp6Z433C+8EfFmYdS4Uv0rA=; b=mE+3aGyq9RsoNcWFVGmbGI06ZZOdCKwmPjcGmlTYr9jb8IyHzQP8I8sQpms7wyuNjt I2Im2j8DLoHwu2e3zRj4uoJYxAYoIi+/2OtrKcGHa6N8a/hBloIOal0xvV/tWnxffJmH Pu82x5yIVS8zlBCnJHNciyVsb6RAaEtPRH4nczzWUobXH3v75MxIPR2Y4cJ73w7xWcTV q1YXVkVF6sXwaXD1kMDcd1/Lx0xW1emnE7xuwWatLHVIr6FmvXhxX1OvGMHH4zP1g89i 3j7MLNuU5SV3mX1JmTeKDig1EtCg7IddYFIvgFoSA7fvm28GK6/7MscUgbEbco3LR1xn hm+Q== X-Gm-Message-State: ALoCoQmdsjXsVWBa9fNjJnUIcA/R4GqZOSZGFxZ78wM3KmKtVv0/3qjzHTfYVxb57jQqRa39fFkJ X-Received: by 10.182.224.231 with SMTP id rf7mr44452obc.77.1414456771724; Mon, 27 Oct 2014 17:39:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Mon, 27 Oct 2014 17:39:11 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> <544EC109.4030600@alvestrand.no> From: Justin Uberti Date: Mon, 27 Oct 2014 17:39:11 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0149c8e26e0aeb050670e199 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4ByetODUrHYktKb3IflOMfBdr4I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 00:39:33 -0000 --089e0149c8e26e0aeb050670e199 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 27, 2014 at 5:29 PM, Eric Rescorla wrote: > > > On Mon, Oct 27, 2014 at 5:25 PM, Martin Thomson > wrote: > >> On 27 October 2014 15:02, Harald Alvestrand wrote: >> > You're confusing the webrtc application (what runs in the browser) with >> the >> > webrtc implementation (the browser itself). Optional NDATA makes the >> browser >> > *more* complex, since it has to expose API surface to let the >> application >> > choose whether or not to offer NDATA, and it has to have code to decide >> > whether or not to offer NDATA. >> >> >> Yes. I don't understand why we would want to say no to making NDATA >> mandatory for browsers, other than to note that not all peers will >> support NDATA. >> > > I agree with this. Let's require what we need. > +1. The fewer optional things we have, the more likely things will Just Work. --089e0149c8e26e0aeb050670e199 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 27, 2014 at 5:29 PM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Mon, Oc= t 27, 2014 at 5:25 PM, Martin Thomson <martin.thomson@gmail.com= > wrote:
On 27 October 20= 14 15:02, Harald Alvestrand <harald@alvestrand.no> wrote:
> You're confusing the webrtc application (what runs in the browser)= with the
> webrtc implementation (the browser itself). Optional NDATA makes the b= rowser
> *more* complex, since it has to expose API surface to let the applicat= ion
> choose whether or not to offer NDATA, and it has to have code to decid= e
> whether or not to offer NDATA.


Yes.=C2=A0 I don't understand why we would want to say no to mak= ing NDATA
mandatory for browsers, other than to note that not all peers will
support NDATA.

I agree with this= . Let's require what we need.
=
+1. The fewer optional things we have, the more likely thing= s will Just Work.=C2=A0
--089e0149c8e26e0aeb050670e199-- From nobody Mon Oct 27 20:41:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF64C1A01E5 for ; Mon, 27 Oct 2014 20:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQoijSI7bnzm for ; Mon, 27 Oct 2014 20:41:34 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513BD1A0364 for ; Mon, 27 Oct 2014 20:41:34 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id x13so2756757wgg.5 for ; Mon, 27 Oct 2014 20:41:33 -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=yedV5al9zRD6VqcL30sLjzBOnZVHJSibzHpx4dfzjbs=; b=dIi/hVKl6Pizi9oevhj4Cf2/rc9lcfYtLQfluvJafIiHu07eRJXYdIcl5+kk6nuY6U yyBlgFGXE+jbpJWYDI9DIyzNxiJXWGNy5hvwdbp39dJEDL0AGQ17XwuSwGoKazS9Oixj lUhbeS2X3m4XVFbD+PjzYjf0l3NBXLrVIr/t7+eCCl6MrUghRMdF83TuyK35AXfuNR1M Xx/BOAeErGZYuSN+cSKSd5iYFvQY6jM9c16apEaT/OhUCjM1kHS3ksZmdDoegzIoMd/r oJpe/K98F/Wdn2RW6APtQdc5/aKZLk/9DowsNwxKd5bFHte8iylX5dFK2UdHypk2ER6L ycIQ== X-Received: by 10.194.206.72 with SMTP id lm8mr735880wjc.70.1414467692974; Mon, 27 Oct 2014 20:41:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.134.196 with HTTP; Mon, 27 Oct 2014 20:41:12 -0700 (PDT) In-Reply-To: References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> <544E7E2B.6040809@gmail.com> <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> From: Bernard Aboba Date: Mon, 27 Oct 2014 20:41:12 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bb70a7262d6d30506736ceb Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/o500W3W1tfcvUJnYspOMTn1OH1k Cc: "" , Colin Perkins Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 03:41:37 -0000 --047d7bb70a7262d6d30506736ceb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Justin said: "I don't think the WG ever explicitly signed up for session-multiplexing of RTX data" [BA] I agree, and in addition would say the same thing with respect to FEC - one of the fundamental objections to RFC 5109 is that it only support session-multiplexing, not SSRC multiplexing. On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti wrote: > > > On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins wrote= : > >> On 27 Oct 2014, at 17:17, Sergio Garcia Murillo < >> sergio.garcia.murillo@gmail.com> wrote: >> >> On 27/10/2014 18:10, Colin Perkins wrote: >> >> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo < >> sergio.garcia.murillo@gmail.com> wrote: >> >> On 27/10/2014 17:45, Colin Perkins wrote: >> >> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo < >> sergio.garcia.murillo@gmail.com> wrote: >> >> On 27/10/2014 17:36, Colin Perkins wrote: >> >> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo < >> sergio.garcia.murillo@gmail.com> wrote: >> >> Not sure if it is done on pourpose, but according to the RTP usage draft= , >> it may seem that full RFC 4588 is mandated at the recevier side: >> >> Receivers are REQUIRED to implement support for RTP retransmission >> packets [RFC4588 ]. >> >> >> That would include both modes, session and ssrc multiplexing. Given the >> extensive usage of bundle and current implementations, session multiplex= ing >> support doesn't make much sense. >> >> Should we drop it, and state that only ssrc-multiplexing shall be >> supported at the receiving end? >> >> >> I don=E2=80=99t see any advantage to doing so, given that support for >> non-BUNDLE sessions is REQUIRED. You need to implement the signalling >> needed for session-multiplexing of retransmission packet anyway, so >> disallowing it buys you nothing. >> >> >> You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I >> don't see is how to do session multiplexing with BUNDLE sessions. >> >> >> You can=E2=80=99t do session multiplexing for BUNDLE sessions; by defin= ition >> they use SSRC multiplexing. You could do non-BUNDLE sessions, with >> retransmission sent on a separate RTP session though. >> >> So, you are saying exactly the same than me. SSRC multiplexing >> supports both BUNDLE and NON-BUNDLE. So, why require support for session >> multiplexing at all? As a developer, I don't see why I would have to >> implement something that would be rarely used and provide no extra benef= it. >> >> >> Non-BUNDLE is session multiplexing. It uses a separate RTP session for >> the retransmissions. >> >> Maybe I am the missing something, if you don't use bundle to send the >> audio/video on same rtpsession, you can still send rtx+video on same >> session. That's it non-bundle with ssrc-multiplexing. Are we referring t= o >> different things? >> >> >> Sure, but that doesn=E2=80=99t alter the fact that the group decided tha= t >> non-BUNDLE media needs to be supported. Sending retransmission on a >> separate RTP session is as needed for interoperability with legacy syste= ms >> as sending audio and video on separate RTP sessions (and shouldn=E2=80= =99t be hard >> to support, since it uses the same mechanisms). >> >> Non-BUNDLE media needs to be supported, but I don't think the WG ever > explicitly signed up for session-multiplexing of RTX data. Unified plan i= s > quite clear in its assertion that the primary, RTX, and FEC flows for a > given media stream should all be represented by a single m=3D line, e.g. > SSRC-multiplexed. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bb70a7262d6d30506736ceb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Justin said:=C2=A0

"I don't think the WG ever= explicitly signed up for session-multiplexing of RTX data"

[BA] I agree, and in addition would say the same thin= g with respect to FEC - one of the fundamental objections to RFC 5109 is th= at it only support session-multiplexing, not SSRC multiplexing. =C2=A0

On Mon, Oc= t 27, 2014 at 5:18 PM, Justin Uberti <juberti@google.com> w= rote:


On Mon, = Oct 27, 2014 at 12:16 PM, Colin Perkins <csp@csperkins.org> = wrote:
On 27 Oct 2014, at 17:17, Sergio Garcia Murillo <sergio.garcia.murillo= @gmail.com> wrote:
=20 =20 =20
On 27/10/2014 18:10, Colin Perkins wrote:
=20 On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@g= mail.com> wrote:
=20
On 27/10/2014 17:45, Colin Perkins wrote:
=20 On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia= .murillo@gmail.com> wrote:
=20
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement =
support for RTP retransmission
   =C2=A0packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don=E2=80=99t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=E2=80=99t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE is session multiplexing. It uses a separate RTP session for the retransmissions.
Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different things?

=
Sure, but that doesn=E2=80=99t alter the fact that the group decided t= hat non-BUNDLE media needs to be supported. Sending retransmission on a sep= arate RTP session is as needed for interoperability with legacy systems as = sending audio and video on separate RTP sessions (and shouldn=E2=80=99t be = hard to support, since it uses the same mechanisms).


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


--047d7bb70a7262d6d30506736ceb-- From nobody Tue Oct 28 01:22:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CBE1A1A17 for ; Tue, 28 Oct 2014 01:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSFHDzWO4Azt for ; Tue, 28 Oct 2014 01:22:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9071A1A03 for ; Tue, 28 Oct 2014 01:22:06 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-29-544f522c989e Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D9.AA.24955.C225F445; Tue, 28 Oct 2014 09:22:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 09:22:03 +0100 From: Christer Holmberg To: Justin Uberti , Eric Rescorla Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3////5gA///tr8CAAFjuAP//7KkQgAAunYCAABOJK///9QMAAAMxDoAABP6FgAAAIFYAAABXLID//28GcA== Date: Tue, 28 Oct 2014 08:22:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CF3E9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> <544EC109.4030600@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4CF3E9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3RlcnyD/E4NYMeYsVr8+xW2ydKmSx 9l87uwOzx4JNpR5Llvxk8pj8uI05gDmKyyYlNSezLLVI3y6BK+PEuTbGgkt+FY0ruRsY9/h0 MXJySAiYSHx9dI8JwhaTuHBvPVsXIxeHkMARRon5Ky5COUsYJeY9WsbSxcjBwSZgIdH9Txuk QUTAReL1vc+MIDazgLrEncXn2EFsYQEHibM7J7FD1DhKtL09zwTSKiJQJ7FlSwhImEVAVeLu vuWsIDavgK9E9/IGdohVT1kl1h45DnYQp0CgxKXHM8DmMAId9/3UGiaIXeISt57MhzpaQGLJ nvPMELaoxMvH/1hBdkkIKEos75eDKM+XuHJ5LjvELkGJkzOfsExgFJ2FZNIsJGWzkJTNAprE LKApsX6XPkSJosSU7ofsELaGROucuezI4gsY2VcxihanFiflphsZ66UWZSYXF+fn6eWllmxi BEbewS2/VXcwXn7jeIhRgINRiYd3A5t/iBBrYllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYExWEph08qjMBL0Vbd83nA5y8ogMLWcOFJNTWneC4eLWXZNfvBQ6 JF3i90QidXfC3brg2XptZinKN0pWr/PqbPi6gns5m1Dzow7fqzJ8pq/nsZw9y8n0xOt79Jzj E8REPpa08Tk+vfW4VUPK9N/WBev+3HEy2dbyL19iW1/W5nclS89k2U2/eF+JpTgj0VCLuag4 EQCiR6oRnQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3DBLfBr1aJuHVLiX0emE46xjq-0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 08:22:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4CF3E9ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklmIHBlb3BsZSB3YW50IHRvIG1ha2UgTkRBVEEgbWFuZGF0b3J5IGZvciBicm93c2Vy cywgZmluZS4NCg0KQnV0LCBteSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZXJlIGlzIGEgdGVjaG5p Y2FsIHJlYXNvbiB0byBtYW5kYXRlIGl0cyB1c2FnZSBmb3IgQ0xVRSwgaWYgQ0xVRSBpcyB0aGUg b25seSB1c2FnZSBvZiB0aGUgZGF0YSBjaGFubmVsPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogMjguIGxva2FrdXV0YSAyMDE0IDI6MzkNClRvOiBF cmljIFJlc2NvcmxhDQpDYzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0g TWVhbmluZyBvZiBTSE9VTEQgc3VwcG9ydC91c2UgaW50ZXJsZWF2aW5nDQoNCg0KDQpPbiBNb24s IE9jdCAyNywgMjAxNCBhdCA1OjI5IFBNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFp bHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQoNCk9uIE1vbiwgT2N0IDI3LCAyMDE0IGF0IDU6 MjUgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1h cnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gMjcgT2N0b2JlciAyMDE0IDE1OjAy LCBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJhbmQubm88bWFpbHRvOmhhcmFsZEBh bHZlc3RyYW5kLm5vPj4gd3JvdGU6DQo+IFlvdSdyZSBjb25mdXNpbmcgdGhlIHdlYnJ0YyBhcHBs aWNhdGlvbiAod2hhdCBydW5zIGluIHRoZSBicm93c2VyKSB3aXRoIHRoZQ0KPiB3ZWJydGMgaW1w bGVtZW50YXRpb24gKHRoZSBicm93c2VyIGl0c2VsZikuIE9wdGlvbmFsIE5EQVRBIG1ha2VzIHRo ZSBicm93c2VyDQo+ICptb3JlKiBjb21wbGV4LCBzaW5jZSBpdCBoYXMgdG8gZXhwb3NlIEFQSSBz dXJmYWNlIHRvIGxldCB0aGUgYXBwbGljYXRpb24NCj4gY2hvb3NlIHdoZXRoZXIgb3Igbm90IHRv IG9mZmVyIE5EQVRBLCBhbmQgaXQgaGFzIHRvIGhhdmUgY29kZSB0byBkZWNpZGUNCj4gd2hldGhl ciBvciBub3QgdG8gb2ZmZXIgTkRBVEEuDQoNCg0KWWVzLiAgSSBkb24ndCB1bmRlcnN0YW5kIHdo eSB3ZSB3b3VsZCB3YW50IHRvIHNheSBubyB0byBtYWtpbmcgTkRBVEENCm1hbmRhdG9yeSBmb3Ig YnJvd3NlcnMsIG90aGVyIHRoYW4gdG8gbm90ZSB0aGF0IG5vdCBhbGwgcGVlcnMgd2lsbA0Kc3Vw cG9ydCBOREFUQS4NCg0KSSBhZ3JlZSB3aXRoIHRoaXMuIExldCdzIHJlcXVpcmUgd2hhdCB3ZSBu ZWVkLg0KDQorMS4gVGhlIGZld2VyIG9wdGlvbmFsIHRoaW5ncyB3ZSBoYXZlLCB0aGUgbW9yZSBs aWtlbHkgdGhpbmdzIHdpbGwgSnVzdCBXb3JrLg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4CF3E9ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SWYgcGVvcGxlIHdhbnQgdG8gbWFrZSBOREFUQSBtYW5kYXRvcnkgZm9yIGJyb3dzZXJz LCBmaW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QnV0LCBteSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZXJlIGlzIGEg dGVjaG5pY2FsIHJlYXNvbiB0byBtYW5kYXRlIGl0cyB1c2FnZSBmb3IgQ0xVRSwgaWYgQ0xVRSBp cyB0aGUgb25seSB1c2FnZSBvZiB0aGUgZGF0YSBjaGFubmVsPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVy dGk8YnI+DQo8Yj5TZW50OjwvYj4gMjguIGxva2FrdXV0YSAyMDE0IDI6Mzk8YnI+DQo8Yj5Ubzo8 L2I+IEVyaWMgUmVzY29ybGE8YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gTWVhbmluZyBvZiBTSE9VTEQgc3VwcG9ydC91c2Ug aW50ZXJsZWF2aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBPY3QgMjcsIDIw MTQgYXQgNToyOSBQTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZt LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgT2N0IDI3LCAyMDE0IGF0IDU6MjUgUE0s IE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNyBPY3RvYmVyIDIw MTQgMTU6MDIsIEhhcmFsZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFs dmVzdHJhbmQubm8iIHRhcmdldD0iX2JsYW5rIj5oYXJhbGRAYWx2ZXN0cmFuZC5ubzwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgWW91J3JlIGNvbmZ1c2luZyB0aGUgd2VicnRjIGFwcGxpY2F0aW9u ICh3aGF0IHJ1bnMgaW4gdGhlIGJyb3dzZXIpIHdpdGggdGhlPGJyPg0KJmd0OyB3ZWJydGMgaW1w bGVtZW50YXRpb24gKHRoZSBicm93c2VyIGl0c2VsZikuIE9wdGlvbmFsIE5EQVRBIG1ha2VzIHRo ZSBicm93c2VyPGJyPg0KJmd0OyAqbW9yZSogY29tcGxleCwgc2luY2UgaXQgaGFzIHRvIGV4cG9z ZSBBUEkgc3VyZmFjZSB0byBsZXQgdGhlIGFwcGxpY2F0aW9uPGJyPg0KJmd0OyBjaG9vc2Ugd2hl dGhlciBvciBub3QgdG8gb2ZmZXIgTkRBVEEsIGFuZCBpdCBoYXMgdG8gaGF2ZSBjb2RlIHRvIGRl Y2lkZTxicj4NCiZndDsgd2hldGhlciBvciBub3QgdG8gb2ZmZXIgTkRBVEEuPGJyPg0KPGJyPg0K PGJyPg0KWWVzLiZuYnNwOyBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHdlIHdvdWxkIHdhbnQgdG8g c2F5IG5vIHRvIG1ha2luZyBOREFUQTxicj4NCm1hbmRhdG9yeSBmb3IgYnJvd3NlcnMsIG90aGVy IHRoYW4gdG8gbm90ZSB0aGF0IG5vdCBhbGwgcGVlcnMgd2lsbDxicj4NCnN1cHBvcnQgTkRBVEEu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdp dGggdGhpcy4gTGV0J3MgcmVxdWlyZSB3aGF0IHdlIG5lZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiYjNDM7MS4gVGhlIGZld2VyIG9wdGlvbmFsIHRoaW5ncyB3ZSBoYXZlLCB0aGUgbW9yZSBsaWtl bHkgdGhpbmdzIHdpbGwgSnVzdCBXb3JrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D4CF3E9ESESSMB209erics_-- From nobody Tue Oct 28 02:10:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776BD1A1AA5 for ; Tue, 28 Oct 2014 02:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM3TeB3J14ZP for ; Tue, 28 Oct 2014 02:10:06 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CCE1A1A84 for ; Tue, 28 Oct 2014 02:10:05 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id h11so867528wiw.0 for ; Tue, 28 Oct 2014 02:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=DhnSzvC3WP374j5iLaiDNwrnNQ2WIqea78xhhi3nR9U=; b=t9BCERgMnGJqvnSFWIQQOHGQZk7b0MKuCVgKoGrjXC1U9jHXVcImEfcUmPmdjoVhQJ BQPWsP6UZ3oZ7cBsMOnyALHCS/kgK5MSr7jAOF8Ca9UCqRZTYI4NfItFsCLmkKHwCoLd W3L9RZeRfpsaE5x2MOGTdXXBwf3hs5k41xNfFEjI9TEdtU3EYA5e0F4iAeZDu46DelPV ZmCLzaC9Hyaih/jZGR3oal6DMWHJVANj3Mlsxr7JN00RS2sjBd8dgFd7yNR/+XhKyA5r QYZEgYmtd6iKJgaL18K+tsNBI9B9lZ/nXmhn4FAuoIx35bSIwrXlWmP/oa8XidTPzPEc Pmmg== X-Received: by 10.181.27.161 with SMTP id jh1mr2883844wid.75.1414487404637; Tue, 28 Oct 2014 02:10:04 -0700 (PDT) Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id cw6sm1076120wjb.18.2014.10.28.02.10.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 02:10:03 -0700 (PDT) Message-ID: <544F5D76.3020907@gmail.com> Date: Tue, 28 Oct 2014 10:10:14 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> <544E7E2B.6040809@gmail.com> <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090003010106010009070101" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ip-_4YZ0deZ2T8kFh-By3nrsOow Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 09:10:07 -0000 This is a multi-part message in MIME format. --------------090003010106010009070101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 28/10/2014 4:41, Bernard Aboba wrote: > Justin said: > > "I don't think the WG ever explicitly signed up for > session-multiplexing of RTX data" > > [BA] I agree, and in addition would say the same thing with respect to > FEC - one of the fundamental objections to RFC 5109 is that it only > support session-multiplexing, not SSRC multiplexing. > +1 Sergio --------------090003010106010009070101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 28/10/2014 4:41, Bernard Aboba wrote:
Justin said: 

"I don't think the WG ever explicitly signed up for session-multiplexing of RTX data"

[BA] I agree, and in addition would say the same thing with respect to FEC - one of the fundamental objections to RFC 5109 is that it only support session-multiplexing, not SSRC multiplexing.  

 
+1
Sergio
--------------090003010106010009070101-- From nobody Tue Oct 28 05:00:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0D81A6FCB for ; Tue, 28 Oct 2014 04:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfSawX1N-SLz for ; Tue, 28 Oct 2014 04:59:50 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F6B1A6F8D for ; Tue, 28 Oct 2014 04:58:47 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 311962F5213F7; Tue, 28 Oct 2014 11:58:44 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9SBwgS3031154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 07:58:42 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 07:58:42 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: AQHP8e/nIllG4P1iiEigF/2tAwwrVZxEXbhogABFpgD//76eMIAAYLCAgACct+A= Date: Tue, 28 Oct 2014 11:58:41 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> <544EC109.4030600@alvestrand.no> In-Reply-To: <544EC109.4030600@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5F5EBDUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uelSkn_cxhWQ-hXSshzPk0dat9s Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 11:59:54 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5F5EBDUS70UWXCHMBA02z_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Monday, October 27, 2014 5:03 PM On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju) wrote: +1 to make N-DATA optional. Data channel provides a robust generic peer to peer communication channel. = So, one can see that data channel may be used under non-webrtc contexts (li= ke as in CLUE) as a general transport or as a replacement of native to SCTP= to traverse firewalls. IMHO, majority of these use cases: a. May just involve a single data channel (with possible multiplexing on to= p of it) b. And may not use the DCEP either (both ends could assume same data channe= l stream id, this is similar to SCTP PPIDs). We already made DCEP(b) as optional. If an app is using just a single data channel then there is no real benefit= in using N-DATA. Then why not make it optional? Also, as already pointed o= ut, making it optional won=92t break interop as it is still negotiated duri= ng SCTP setup time anyway. Negotiation means that transport initiator gets to choose whether to use it= or not. This means that a responder has no choice in the matter. In the situation where the responder knows better than the initiator what t= he usage is going to be, this is problematic. IMHO, it is not just the responder knowing =93better=94 which makes a scena= rio work, rather both have to agree on it. For example, if responder wants = to have multiple data channels is no good if the originator does not want t= o support (CLUE use of data channels is an example of it). That=92s why, in= most cases I know it is the originator who offers capabilities and termina= tor gets to choose. I would like to point out that there will be some webrtc applications which= might just use one webrtc data channel for simplicity (and may use some mu= ltiplexing of different types of msgs/objects on top of it) or one is just = sufficient as the app does not send/recv huge chunks of data. So, N-DATA is= n=92t needed for such webrtc clients either. Then why add burden to such we= brtc implementations!? You're confusing the webrtc application (what runs in the browser) with the= webrtc implementation (the browser itself). Optional NDATA makes the brows= er *more* complex, since it has to expose API surface to let the applicatio= n choose whether or not to offer NDATA, and it has to have code to decide w= hether or not to offer NDATA. I am talking about 2 items: 1. Making NDATA a MUST data channel draft? I could be wrong, but I th= ought this is the main discussion point in this thread! This is a burden on= non-webrtc users of data channel. My understanding is data channels are me= ant to be used by non-webrtc as a general protocol. Please correct me if my= understanding is not correct. 2. Making NDATA a MUST for webrtc clients? I am not just talking abou= t browser, but non-browser based native/hybrid webrtc clients (e.g. a thin = webrtc client on a cable set top box) as well. Browsers can implement it as= a MUST clause, no one is stopping that. But why mandate a set top box (or = an IoT device) implement NDATA when it just wants to use a single data chan= nel only?! Let=92s take an example: We keep NDATA a MUST. During SCTP setup, if NDATA = is not supported at the peer then will the SCTP setup be abandoned? If the = SCTP association is not abandoned then there is no point in making it a MUS= T where as in real practice it is not enforced as a MUST. BR Raju From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Monday, October 27, 2014 3:11 PM To: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving Hi, We shall not add burden just because there are bad programmers out there - = they will anyway always manage to use our specs in a wrong way :) Regards, Christer Sent from my Windows Phone ________________________________ From: Harald Alvestrand Sent: =FD27/=FD10/=FD2014 22:00 To: Christer Holmberg; rtcweb@ietf.o= rg Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving On 10/27/2014 11:41 AM, Christer Holmberg wrote: > Hi, > >>>>> Within the CLUE WG, we had a discussion regarding the following state= ment in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >>>>> >>>>> "The support for message interleaving as defined in >>>>> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >>>>> >>>>> First, it is a little unclear what "the support SHOULD be used" means= . >>>> My understanding is that SCTP implementations supporting the extension= will use it. >>>> This is negotiated during the setup of the SCTP association. >>> If it's done on SCTP level, why do we need to talk about it in the data= channel draft? >>> >>> Is there a reason why it is important to use it for data channels? If s= o, does it apply to data channels in general? >> NDATA was added in order to avoid head-of-line blocking on the transport= (if I understand this correctly, until >> this was added, sending a huge message would block the delivery of small= messages on all channels until the huge message was fully delivered). >> >> Unlike Michael, I see no reason to make this a SHOULD; I think it should= be a MUST, and the older >> implementations in browsers should just be called out as non-conformant. >> >> That said, I think that data channels ought to interoperate successfully= with implementations that don't support the >> extension - but data channel implementations in WebRTC endpoints should = be under a "MUST implement, MUST offer" ruleset. > First, keep in mind that I am NOT talking about WebRTC endpoints (which i= s one reason we shouldn't call it webrtc data channel to begin with, but th= at's another story...), but ANY type of endpoint that wants to use a data c= hannel. I'm a bit self-centric on behalf of WebRTC, but I feel the other way - that it might have been a mistake to float the option of saying "other things can use these features", and that we should admit only arguments that bear upon their usage in WebRTC. I'm not sure I have WG consensus (even rough consensus) on this point, however. > > Second, I am not talking about MUST support, but MUST use/offer. > > Assume I have a CLUE endpoint, which will use a data channel ONLY to tran= sport CLUE messages. CLUE messages aren't that hugeto begin with, and there= will be no blocking of small messages on other channels - as there are no = other channels. > > So, why does the CLUE endpoint need to offer interleaving? Flipping the question around - if a programming mistake in the Javascript implementing a CLUE endpoint in a WebRTC browser happens to send a multimegabyte-sized object down the (out of order) datachannel, is it OK to have all the subsequent CLUE messages delivered 30 seconds late= ? -- Surveillance is pervasive. Go Dark. -- Surveillance is pervasive. Go Dark. --_000_E1FE4C082A89A246A11D7F32A95A17828E5F5EBDUS70UWXCHMBA02z_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Monday, October 27, 2014 5:03 PM

On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju)= wrote:

+1 to make N-DATA opt= ional.

 <= /p>

Data channel provides a r= obust generic peer to peer communication channel. So, one can see that data= channel may be used under non-webrtc contexts (like as in CLUE) as a general transport or as a replacement of native to SCTP to t= raverse firewalls. IMHO, majority of these use cases:

a. May just involve a sin= gle data channel (with possible multiplexing on top of it)

b. And may not use the DC= EP either (both ends could assume same data channel stream id, this is simi= lar to SCTP PPIDs).

We already made DCEP(b) a= s optional.

 <= /p>

If an app is using just a= single data channel then there is no real benefit in using N-DATA. Then wh= y not make it optional? Also, as already pointed out, making it optional won=92t break interop as it is still negotiated during SCTP se= tup time anyway.


Negotiation means that transport initiator gets to choose whether to use it= or not.
This means that a responder has no choice in the matter.

In the situation where the responder knows better than the initiator what t= he usage is going to be, this is problematic.=

<Raju>

IMHO, it is not just t= he responder knowing =93better=94 which makes a scenario work, rather both = have to agree on it. For example, if responder wants to have multiple data = channels is no good if the originator does not want to support (CLUE use of data channels is an example of it). That= =92s why, in most cases I know it is the originator who offers capabilities= and terminator gets to choose.

</Raju>


 <= /p>

I would like to point out= that there will be some webrtc applications which might just use one webrt= c data channel for simplicity (and may use some multiplexing of different types of msgs/objects on top of it) or one is just sufficient= as the app does not send/recv huge chunks of data. So, N-DATA isn=92t need= ed for such webrtc clients either. Then why add burden to such webrtc imple= mentations!?


You're confusing the webrtc application (what runs in the browser) with the= webrtc implementation (the browser itself). Optional NDATA makes the brows= er *more* complex, since it has to expose API surface to let the applicatio= n choose whether or not to offer NDATA, and it has to have code to decide whether or not to offer NDATA.

<Raju>

I am talking about = 2 items:

1.       Mak= ing NDATA a MUST data channel draft? I could be wrong, but I thought this i= s the main discussion point in this thread! This is a burden on non-webrtc users of data channel. My understanding is data chann= els are meant to be used by non-webrtc as a general protocol. Please correc= t me if my understanding is not correct.

2.       Mak= ing NDATA a MUST for webrtc clients? I am not just talking about browser, b= ut non-browser based native/hybrid webrtc clients (e.g. a thin webrtc client on a cable set top box) as well. Browsers can impleme= nt it as a MUST clause, no one is stopping that. But why mandate a set top = box (or an IoT device) implement NDATA when it just wants to use a single d= ata channel only?!

Let=92s take= an example: We keep NDATA a MUST. During SCTP setup, if NDATA is not suppo= rted at the peer then will the SCTP setup be abandoned? If the SCTP association is not abandoned then there is no point in making it = a MUST where as in real practice it is not enforced as a MUST.

</Raju><= /o:p>

 

BR

Raju 

 

 <= /p>

 <= /p>

 

Hi,

We shall not add burden just because there are bad programmers out there - = they will anyway always manage to use our specs in a wrong way :)

Regards,

Christer

Sent from my Windows Phone

From: Harald Alve= strand
Sent: =FD27/=FD10/=FD2014 22:00
To: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

On 10/27/2014 11:41 AM, Christer Holmberg wrote:
> Hi,
>
>>>>> Within the CLUE WG, we had a discussion regarding the = following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt= :
>>>>> 
>>>>> "The support for message interleaving as defined = in
>>>>>         &= nbsp;       [I-D.ietf-tsvwg-sctp-ndata] SHOUL= D be used."
>>>>> 
>>>>> First, it is a little unclear what "the support S= HOULD be used" means.
>>>> My understanding is that SCTP implementations supporting t= he extension will use it.
>>>> This is negotiated during the setup of the SCTP associatio= n.
>>> If it's done on SCTP level, why do we need to talk about it in= the data channel draft?
>>>
>>> Is there a reason why it is important to use it for data chann= els? If so, does it apply to data channels in general?
>> NDATA was added in order to avoid head-of-line blocking on the tra= nsport (if I understand this correctly, until
>> this was added, sending a huge message would block the delivery of= small messages on all channels until the huge message was fully delivered)= .
>>
>> Unlike Michael, I see no reason to make this a SHOULD; I think it = should be a MUST, and the older
>> implementations in browsers should just be called out as non-confo= rmant.
>>
>> That said, I think that data channels ought to interoperate succes= sfully with implementations that don't support the
>> extension - but data channel implementations in WebRTC endpoints s= hould be under a "MUST implement, MUST offer" ruleset.
> First, keep in mind that I am NOT talking about WebRTC endpoints (whic= h is one reason we shouldn't call it webrtc data channel to begin with, but= that's another story...), but ANY type of endpoint that wants to use a dat= a channel.

I'm a bit self-centric on behalf of WebRTC, but I feel the other way -
that it might have been a mistake to float the option of saying "other=
things can use these features", and that we should admit only argument= s
that bear upon their usage in WebRTC.

I'm not sure I have WG consensus (even rough consensus) on this point,
however.
>
> Second, I am not talking about MUST support, but MUST use/offer.
>
> Assume I have a CLUE endpoint, which will use a data channel ONLY to t= ransport CLUE messages. CLUE messages aren't that hugeto begin with, and th= ere will be no blocking of small messages on other channels - as there are = no other channels.
>
> So, why does the CLUE endpoint need to offer interleaving?

Flipping the question around - if a programming mistake in the
Javascript implementing a CLUE endpoint in a WebRTC browser happens to
send a multimegabyte-sized object down the (out of order) datachannel,
is it OK to have all the subsequent CLUE messages delivered 30 seconds late= ?



--
Surveillance is pervasive. Go Dark.





-- 
Surveillance is pervasive. Go Dark.
--_000_E1FE4C082A89A246A11D7F32A95A17828E5F5EBDUS70UWXCHMBA02z_-- From nobody Tue Oct 28 05:12:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807DC1A7113 for ; Tue, 28 Oct 2014 05:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0XEttKgpfFY for ; Tue, 28 Oct 2014 05:12:07 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575711A1BED for ; Tue, 28 Oct 2014 05:07:38 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 8C1B18151070A; Tue, 28 Oct 2014 12:07:35 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9SC7YYL010326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 08:07:37 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 08:07:35 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Michael Tuexen Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: AQHP8e/nIllG4P1iiEigF/2tAwwrVZxEXbhogABFpgD//76eMIAAVKsAgACyvLA= Date: Tue, 28 Oct 2014 12:07:34 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> <7DCAE2C4-A587-463C-A6B4-4FC609CAA985@lurchi.franken.de> In-Reply-To: <7DCAE2C4-A587-463C-A6B4-4FC609CAA985@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vdT__rcMc4gIK6-DSgmXpo_daks Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 12:12:09 -0000 > > +1 to make N-DATA optional. > > > > Data channel provides a robust generic peer to peer communication chann= el. > So, one can see that data channel may be used under non-webrtc contexts > (like as in CLUE) as a general transport or as a replacement of native to > SCTP to traverse firewalls. IMHO, majority of these use cases: > > a. May just involve a single data channel (with possible multiplexing o= n > top of it) > > b. And may not use the DCEP either (both ends could assume same data > channel stream id, this is similar to SCTP PPIDs). > > We already made DCEP(b) as optional. > > > > If an app is using just a single data channel then there is no real > benefit in using N-DATA. Then why not make it optional? Also, as already > pointed out, making it optional won't break interop as it is still > negotiated during SCTP setup time anyway. > > > > I would like to point out that there will be some webrtc applications > which might just use one webrtc data channel for simplicity (and may use > some multiplexing of different types of msgs/objects on top of it) or one= is > just sufficient as the app does not send/recv huge chunks of data. So, N- > DATA isn't needed for such webrtc clients either. Then why add burden to > such webrtc implementations!? > Are you implementing this? I would say that adding N-DATA to an SCTP > implementation with support > for Stream Reconfiguration and PR-SCTP does not increase the complexity > substantially... I don't think the question is really about if NDATA adds complexity or not. NDATA is a new capability to be added to SCTP stacks; and adding it takes resources to develop, test, deliver, deploy/update. As I just responded to Harald's post, we need to look at it from data channel use in non-webrtc contexts and also data channel use for non-browser webrtc clients. Just focusing on webrtc+browser alone is not fair as not all the webrtc or non-webrtc data channel implementation= s can keep up with the same pace as browsers do; also they don't have resources like browser companies do!! BR Raju From nobody Tue Oct 28 06:27:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFA81A8789 for ; Tue, 28 Oct 2014 06:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2br4cCPeeiM for ; Tue, 28 Oct 2014 06:27:25 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 84B831A8828 for ; Tue, 28 Oct 2014 06:27:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9D7E97C5278; Tue, 28 Oct 2014 14:27:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpZovzETaU_m; Tue, 28 Oct 2014 14:27:06 +0100 (CET) Received: from [192.168.1.238] (67-203-153-2.static-ip.telepacific.net [67.203.153.2]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0DD1E7C526F; Tue, 28 Oct 2014 14:27:04 +0100 (CET) Message-ID: <544F99A5.2090005@alvestrand.no> Date: Tue, 28 Oct 2014 06:27:01 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , Christer Holmberg , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> <544EC109.4030600@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020407030206000903010204" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5M3SHxWSYwbc6FK47GzUonvpAfQ Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 13:27:31 -0000 This is a multi-part message in MIME format. --------------020407030206000903010204 Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: quoted-printable On 10/28/2014 04:58 AM, Makaraju, Maridi Raju (Raju) wrote: > > =20 > > =20 > > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Monday, October 27, 2014 5:03 PM > > On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju) wrote: > > +1 to make N-DATA optional. > > =20 > > Data channel provides a robust generic peer to peer communication > channel. So, one can see that data channel may be used under > non-webrtc contexts (like as in CLUE) as a general transport or as > a replacement of native to SCTP to traverse firewalls. IMHO, > majority of these use cases: > > a. May just involve a single data channel (with possible > multiplexing on top of it) > > b. And may not use the DCEP either (both ends could assume same > data channel stream id, this is similar to SCTP PPIDs). > > We already made DCEP(b) as optional. > > =20 > > If an app is using just a single data channel then there is no > real benefit in using N-DATA. Then why not make it optional? Also, > as already pointed out, making it optional won=92t break interop as= > it is still negotiated during SCTP setup time anyway. > > > Negotiation means that transport initiator gets to choose whether to > use it or not. > This means that a responder has no choice in the matter. > > In the situation where the responder knows better than the initiator > what the usage is going to be, this is problematic. > > > > IMHO, it is not just the responder knowing =93better=94 which makes a > scenario work, rather both have to agree on it. For example, if > responder wants to have multiple data channels is no good if the > originator does not want to support (CLUE use of data channels is an > example of it). That=92s why, in most cases I know it is the originator= > who offers capabilities and terminator gets to choose. > > > > > =20 > > I would like to point out that there will be some webrtc applications > which might just use one webrtc data channel for simplicity (and may > use some multiplexing of different types of msgs/objects on top of it) > or one is just sufficient as the app does not send/recv huge chunks of > data. So, N-DATA isn=92t needed for such webrtc clients either. Then wh= y > add burden to such webrtc implementations!? > > > You're confusing the webrtc application (what runs in the browser) > with the webrtc implementation (the browser itself). Optional NDATA > makes the browser *more* complex, since it has to expose API surface > to let the application choose whether or not to offer NDATA, and it > has to have code to decide whether or not to offer NDATA. > > > > I am talking about 2 items: > > 1. Making NDATA a MUST data channel draft? I could be wrong, but > I thought this is the main discussion point in this thread! This is a > burden on non-webrtc users of data channel. My understanding is data > channels are meant to be used by non-webrtc as a general protocol. > Please correct me if my understanding is not correct. > Your understanding may be right or wrong, but it's different from mine. Data channels are created to be useful for WebRTC. That's their purpose in being created, so WebRTC requirements take precedence over all other requirements. NDATA makes them more useful for WebRTC (or, as Martin put it, "without NDATA, they're not fit for purpose"). Optional NDATA makes things more complex for WebRTC. Therefore, seen from a WebRTC viewpoint, speaking in the RTCWEB WG, I think NDATA should be mandatory. > 2. Making NDATA a MUST for webrtc clients? I am not just talking > about browser, but non-browser based native/hybrid webrtc clients > (e.g. a thin webrtc client on a cable set top box) as well. Browsers > can implement it as a MUST clause, no one is stopping that. But why > mandate a set top box (or an IoT device) implement NDATA when it just > wants to use a single data channel only?! > > Let=92s take an example: We keep NDATA a MUST. During SCTP setup, if > NDATA is not supported at the peer then will the SCTP setup be > abandoned? If the SCTP association is not abandoned then there is no > point in making it a MUST where as in real practice it is not enforced > as a MUST. > In general, when an application connects to something that does not conform to the spec for the protocol he's using, "all bets are off". Implementations are free to handle this situation whatever way they want.= Note: So far, I've seen *zero* evidence that the burden of implementing NDATA is significantly higher than the total effort spent in writing updates on this thread. For 90+% of all implementors, not implementing NDATA is a larger effort than implementing it, because the libraries they use will support it, so they have to take action to take it out. --------------020407030206000903010204 Content-Type: text/html; charset=windows-1255 Content-Transfer-Encoding: 8bit
On 10/28/2014 04:58 AM, Makaraju, Maridi Raju (Raju) wrote:

 

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Monday, October 27, 2014 5:03 PM

On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju) wrote:

+1 to make N-DATA optional.

 

Data channel provides a robust generic peer to peer communication channel. So, one can see that data channel may be used under non-webrtc contexts (like as in CLUE) as a general transport or as a replacement of native to SCTP to traverse firewalls. IMHO, majority of these use cases:

a. May just involve a single data channel (with possible multiplexing on top of it)

b. And may not use the DCEP either (both ends could assume same data channel stream id, this is similar to SCTP PPIDs).

We already made DCEP(b) as optional.

 

If an app is using just a single data channel then there is no real benefit in using N-DATA. Then why not make it optional? Also, as already pointed out, making it optional won’t break interop as it is still negotiated during SCTP setup time anyway.


Negotiation means that transport initiator gets to choose whether to use it or not.
This means that a responder has no choice in the matter.

In the situation where the responder knows better than the initiator what the usage is going to be, this is problematic.

<Raju>

IMHO, it is not just the responder knowing “better” which makes a scenario work, rather both have to agree on it. For example, if responder wants to have multiple data channels is no good if the originator does not want to support (CLUE use of data channels is an example of it). That’s why, in most cases I know it is the originator who offers capabilities and terminator gets to choose.

</Raju>


 

I would like to point out that there will be some webrtc applications which might just use one webrtc data channel for simplicity (and may use some multiplexing of different types of msgs/objects on top of it) or one is just sufficient as the app does not send/recv huge chunks of data. So, N-DATA isn’t needed for such webrtc clients either. Then why add burden to such webrtc implementations!?


You're confusing the webrtc application (what runs in the browser) with the webrtc implementation (the browser itself). Optional NDATA makes the browser *more* complex, since it has to expose API surface to let the application choose whether or not to offer NDATA, and it has to have code to decide whether or not to offer NDATA.

<Raju>

I am talking about 2 items:

1.       Making NDATA a MUST data channel draft? I could be wrong, but I thought this is the main discussion point in this thread! This is a burden on non-webrtc users of data channel. My understanding is data channels are meant to be used by non-webrtc as a general protocol. Please correct me if my understanding is not correct.


Your understanding may be right or wrong, but it's different from mine.

Data channels are created to be useful for WebRTC. That's their purpose in being created, so WebRTC requirements take precedence over all other requirements.

NDATA makes them more useful for WebRTC (or, as Martin put it, "without NDATA, they're not fit for purpose").

Optional NDATA makes things more complex for WebRTC.

Therefore, seen from a WebRTC viewpoint, speaking in the RTCWEB WG, I think NDATA should be mandatory.

2.       Making NDATA a MUST for webrtc clients? I am not just talking about browser, but non-browser based native/hybrid webrtc clients (e.g. a thin webrtc client on a cable set top box) as well. Browsers can implement it as a MUST clause, no one is stopping that. But why mandate a set top box (or an IoT device) implement NDATA when it just wants to use a single data channel only?!

Let’s take an example: We keep NDATA a MUST. During SCTP setup, if NDATA is not supported at the peer then will the SCTP setup be abandoned? If the SCTP association is not abandoned then there is no point in making it a MUST where as in real practice it is not enforced as a MUST.


In general, when an application connects to something that does not conform to the spec for the protocol he's using, "all bets are off".

Implementations are free to handle this situation whatever way they want.

Note: So far, I've seen *zero* evidence that the burden of implementing NDATA is significantly higher than the total effort spent in writing updates on this thread. For 90+% of all implementors, not implementing NDATA is a larger effort than implementing it, because the libraries they use will support it, so they have to take action to take it out.

--------------020407030206000903010204-- From nobody Tue Oct 28 06:51:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780CE1A888F for ; Tue, 28 Oct 2014 06:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmT53JlWPUDz for ; Tue, 28 Oct 2014 06:51:12 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3DC1A87BF for ; Tue, 28 Oct 2014 06:51:11 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-b9-544f9f4d025a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EB.ED.04081.D4F9F445; Tue, 28 Oct 2014 14:51:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 14:51:08 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3////5gA///tr8CAAFjuAP//7KkQgAAtDgCAABO7S///8JGA//7IDGA= Date: Tue, 28 Oct 2014 13:51:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> In-Reply-To: <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvja7vfP8Qg8dzFCyO9XWxWVxsWsJo sfZfO7sDs8eVCVdYPZYs+cnksaFlB1MAcxSXTUpqTmZZapG+XQJXxtKzLSwFq9kqrv/fw9jA OJm1i5GTQ0LAROL6s72MELaYxIV769lAbCGBI4wSi/d5Q9hLgOxnAV2MHBxsAhYS3f+0QcIi AqYSB5fPYwGxmQWCJXq7IEYKCzhInN05iR2ixlGi7e15JpBWEYEkicbdrCAmi4CqxKLb9SAV vAK+Ett/vgeq4AJa9JpZ4tnVJWAXcAq4SkzdtocZxGYEuuz7qTVMEKvEJW49mc8EcbGAxJI9 55khbFGJl4//gc2XEFCUWN4vB1GuI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkqmzkLTM QtIyC0nLAkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBsXRwy2+DHYwvnzseYhTgYFTi 4TUo9w8RYk0sK67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M/m7L vJXeBus99OarjUjJSaj+sv9J1rY7XxK/sx3pTPEXS7tjOv/zh+w/rouf+UT+sluS3BUXv8v+ UFFP2/qOJh/dKWGv+uUTQ171Fq7L3dviYz9l6dWQRQbp3ZKMTSuLYgT6V0vM1D5zrmKrx5Yn BfOiv5y2FV0quOc748oTy2tjQ40TY4KVWIozEg21mIuKEwEBcUMThgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/P0D4xIx5W2_WpUhUwJVozmjzn8E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 13:51:13 -0000 Hi, >> I am not suggesting different flavors - I am suggesting to make the usag= e of interleaving optional. Other SCTP features are also optional (includin= g reliability, ordering etc). > > Where are these things optional? According to > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.1 > an implementation MUST implement PR-SCTP and the support of the FORWARD-T= SN chunk will be negotiated similar to the NDATA chunk. I don't see a diffe= rence, especially not if we move to MUST support NDATA. For example, section 6.1 says: "The partial reliability extension defined in [RFC3758] MUST be supported.= " However, in CLUE we say that a CLUE entity MUST NOT *use* the extension, as= all CLUE messages are required to be sent reliably. Regards, Christer From nobody Tue Oct 28 08:06:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B5C1A8A5F for ; Tue, 28 Oct 2014 08:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0-YSVhDNGoR for ; Tue, 28 Oct 2014 08:06:40 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22A91A8A5A for ; Tue, 28 Oct 2014 08:06:39 -0700 (PDT) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DB3821C10461D; Tue, 28 Oct 2014 16:06:36 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> Date: Tue, 28 Oct 2014 16:06:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r15U18uDgjPhv6d6ADPEB5ObVaw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 15:06:43 -0000 On 28 Oct 2014, at 14:51, Christer Holmberg = wrote: > Hi, >=20 >>> I am not suggesting different flavors - I am suggesting to make the = usage of interleaving optional. Other SCTP features are also optional = (including reliability, ordering etc). >>=20 >> Where are these things optional? According to >> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.1 >> an implementation MUST implement PR-SCTP and the support of the = FORWARD-TSN chunk will be negotiated similar to the NDATA chunk. I don't = see a difference, especially not if we move to MUST support NDATA. >=20 > For example, section 6.1 says: >=20 > "The partial reliability extension defined in [RFC3758] MUST be = supported." >=20 > However, in CLUE we say that a CLUE entity MUST NOT *use* the = extension, as all CLUE messages are required to be sent reliably. That is OK. However, support for PR-SCTP MUST be there and it will be = negotiated. You just never send a message with partial reliability. At least this is my = understanding... Best regards Michael >=20 > Regards, >=20 > Christer >=20 From nobody Tue Oct 28 08:46:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542D91A8942 for ; Tue, 28 Oct 2014 08:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWH1IOXOkau6 for ; Tue, 28 Oct 2014 08:46:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E801A0231 for ; Tue, 28 Oct 2014 08:46:43 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-62-544fba6121a3 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 87.D6.04387.16ABF445; Tue, 28 Oct 2014 16:46:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 16:46:40 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3////5gA///tr8CAAFjuAP//7KkQgAAtDgCAABO7S///8JGA//7IDGD//YqpAP/6+gaQ Date: Tue, 28 Oct 2014 15:46:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW7iLv8Qg69XZCyO9XWxWVxsWsJo sfZfO7sDs8eVCVdYPZYs+cnksaFlB1MAcxSXTUpqTmZZapG+XQJXxoH7H9kKbnFWvL1wjq2B 8RV7FyMnh4SAicSlb/OhbDGJC/fWs3UxcnEICRxhlNh5fzM7hLOEUeLGrqVAGQ4ONgELie5/ 2iANIgKmEgeXz2MBsZkFgiV6uyazgtjCAg4SZ3dOYoeocZRoe3ueCcLOk9hzfyEjyBgWAVWJ xyvyQcK8Ar4Sj+9tYIRY9YpFYt7UZWC9nAKuEpfmLACzGYGO+35qDRPELnGJW0/mM0EcLSCx ZM95ZghbVOLl43+sELaSxKLbn6HqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrNQjJ2FpKW WUhaZiFpWcDIsopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMKYObvlttYPx4HPHQ4wCHIxK PLwb2PxDhFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo+2J c9vUG2RC3r3wdCsIexzVv5x50s3Ds7fP3OtzX4ot71PqKub6rcfD9/73YWpJfPjFZ8f+uIO7 Vr75NumA5DWHo4brmhc4c79u3ltrmvdsYcf3z7sCfr7fVfTgl3j3dLErf3XXXOqeVbaLiffs o3zn/zL19oIT1TWsD/SvVV52c9sNxXqOO71KLMUZiYZazEXFiQCRWTdaigIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Nm6SXEQpHl4fKEAXZh7rWXWyYG8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 15:46:46 -0000 Hi, >>> I am not suggesting different flavors - I am suggesting to make the usa= ge of=20 >>> interleaving optional. Other SCTP features are also optional (including= reliability, ordering etc). >>>=20 >>> Where are these things optional? According to >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section >>> -6.1 an implementation MUST implement PR-SCTP and the support of the=20 >>> FORWARD-TSN chunk will be negotiated similar to the NDATA chunk. I don'= t see a difference, especially not if we move to MUST support NDATA. >>=20 >> For example, section 6.1 says: >>=20 >> "The partial reliability extension defined in [RFC3758] MUST be support= ed." >>=20 >> However, in CLUE we say that a CLUE entity MUST NOT *use* the extension,= as all CLUE messages are required to be sent reliably. > > That is OK. However, support for PR-SCTP MUST be there and it will be neg= otiated. You just never send a message with partial reliability. At least t= his is my understanding... So, can the same be done for interleaving? I.e. the support MUST be there, = but e.g. CLUE entities can choose not to use it? Note that my issue is not about support, it's about usage :) Regards, Christer From nobody Tue Oct 28 09:27:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E691D1A8AE5 for ; Tue, 28 Oct 2014 09:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLMBxEqgneMb for ; Tue, 28 Oct 2014 09:27:23 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35AC1A8AE2 for ; Tue, 28 Oct 2014 09:26:13 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so2151276wiv.8 for ; Tue, 28 Oct 2014 09:26:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UtvYRVP5SyI35B9ikfWiulXCQlZpqlwFI4hY/hUznWg=; b=aoSn8gDg2jLD4MI24xcn6YKo/z088IYJBY0eJDb3RfLCl+3lVi/iWiwyGSCd5z+CQr 30mrdM2jEZW7XLEk/KNSATALiA2zgESfImn8t4ZpgyZ/xGoJvFHGngAW5AcMtEOTAkJp XNfxbFdASs0Y4dH8q5Mbo+Wr5HUGCkzyeoMYaSM8oxdm38fa+RqS+iAkrE1H7moznOkv sS4KLrLUYij3SReNBSie2ykq5s0FyEW4rw7KIHp3CeVVP+4p4wDyPp7SRTPj22X2VOTl jGB7ycLzimXHIsfQCNTe0cWw9AawCzV+L/Fxf4+GnIaEv1SkzqogzCpZ/MHpulETH4GO U5Ag== X-Gm-Message-State: ALoCoQnwT0X7Tvy6FCECeYhm2EHCVHzKiDKCnxEnWuU4lLerQAG8slatPRlNOPP/0DedX+i6hLPW X-Received: by 10.181.13.20 with SMTP id eu20mr29101028wid.36.1414513572342; Tue, 28 Oct 2014 09:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Tue, 28 Oct 2014 09:25:32 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Tue, 28 Oct 2014 09:25:32 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d043bdff80285b105067e1b3d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GxKewwwrbDBSGuP0Wy-5hUU4_Lk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 16:27:25 -0000 --f46d043bdff80285b105067e1b3d Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 8:46 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> I am not suggesting different flavors - I am suggesting to make the > usage of > >>> interleaving optional. Other SCTP features are also optional > (including reliability, ordering etc). > >>> > >>> Where are these things optional? According to > >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section > >>> -6.1 an implementation MUST implement PR-SCTP and the support of the > >>> FORWARD-TSN chunk will be negotiated similar to the NDATA chunk. I > don't see a difference, especially not if we move to MUST support NDATA. > >> > >> For example, section 6.1 says: > >> > >> "The partial reliability extension defined in [RFC3758] MUST be > supported." > >> > >> However, in CLUE we say that a CLUE entity MUST NOT *use* the > extension, as all CLUE messages are required to be sent reliably. > > > > That is OK. However, support for PR-SCTP MUST be there and it will be > negotiated. You just never send a message with partial reliability. At > least this is my understanding... > > So, can the same be done for interleaving? I.e. the support MUST be there, > but e.g. CLUE entities can choose not to use it? > > Note that my issue is not about support, it's about usage :) What resource is being conserved by not just requiring it? -Ekr --f46d043bdff80285b105067e1b3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 28, 2014 at 8:46 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi,

>>> I am not suggesting different flavors - I am suggesting to mak= e the usage of
>>> interleaving optional. Other SCTP features are also optional (= including reliability, ordering etc).
>>>
>>> Where are these things optional? According to
>>> https://tools.ietf.org/html/draft-iet= f-rtcweb-data-channel-12#section
>>> -6.1 an implementation MUST implement PR-SCTP and the s= upport of the
>>> FORWARD-TSN chunk will be negotiated similar = to the NDATA chunk. I don't see a difference, especially not if we move= to MUST support NDATA.
>>
>> For example, section 6.1 says:
>>
>>=C2=A0 =C2=A0 =C2=A0 "The partial reliability extension define= d in [RFC3758] MUST be supported."
>>
>> However, in CLUE we say that a CLUE entity MUST NOT *use* the exte= nsion, as all CLUE messages are required to be sent reliably.
>
> That is OK. However, support for PR-SCTP MUST be there and it will be = negotiated. You just never send a message with partial reliability. At leas= t this is my understanding...

So, can the same be done for interleaving? I.e. the support MUST be = there, but e.g. CLUE entities can choose not to use it?

Note that my issue is not about support, it's about usage :)

What resource is being conserved by not just requirin= g it?

-Ekr
--f46d043bdff80285b105067e1b3d-- From nobody Tue Oct 28 10:03:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679551A894E for ; Tue, 28 Oct 2014 10:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hDFW_0qLOwM for ; Tue, 28 Oct 2014 10:02:57 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2BF1A8F4D for ; Tue, 28 Oct 2014 10:02:52 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 353F9C615828E; Tue, 28 Oct 2014 17:02:49 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9SH2jnL010952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 13:02:45 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 13:02:45 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: AQHP8e/nIllG4P1iiEigF/2tAwwrVZxEXbhogABFpgD//76eMIAAYLCAgACct+CAAGWBgP//z7+w Date: Tue, 28 Oct 2014 17:02:44 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se>, <544EA473.6040700@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CEBED@ESESSMB209.ericsson.se> <544EC109.4030600@alvestrand.no> <544F99A5.2090005@alvestrand.no> In-Reply-To: <544F99A5.2090005@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5F6685US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6uS6cklxtBshTpPGhWRwS4qVvSE Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 17:03:05 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5F6685US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see my comments inline. From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Tuesday, October 28, 2014 8:27 AM From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Monday, October 27, 2014 5:03 PM On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju) wrote: +1 to make N-DATA optional. Data channel provides a robust generic peer to peer communication channel. = So, one can see that data channel may be used under non-webrtc contexts (li= ke as in CLUE) as a general transport or as a replacement of native to SCTP= to traverse firewalls. IMHO, majority of these use cases: a. May just involve a single data channel (with possible multiplexing on to= p of it) b. And may not use the DCEP either (both ends could assume same data channe= l stream id, this is similar to SCTP PPIDs). We already made DCEP(b) as optional. If an app is using just a single data channel then there is no real benefit= in using N-DATA. Then why not make it optional? Also, as already pointed o= ut, making it optional won't break interop as it is still negotiated during= SCTP setup time anyway. Negotiation means that transport initiator gets to choose whether to use it= or not. This means that a responder has no choice in the matter. In the situation where the responder knows better than the initiator what t= he usage is going to be, this is problematic. IMHO, it is not just the responder knowing "better" which makes a scenario = work, rather both have to agree on it. For example, if responder wants to h= ave multiple data channels is no good if the originator does not want to su= pport (CLUE use of data channels is an example of it). That's why, in most = cases I know it is the originator who offers capabilities and terminator ge= ts to choose. I would like to point out that there will be some webrtc applications which= might just use one webrtc data channel for simplicity (and may use some mu= ltiplexing of different types of msgs/objects on top of it) or one is just = sufficient as the app does not send/recv huge chunks of data. So, N-DATA is= n't needed for such webrtc clients either. Then why add burden to such webr= tc implementations!? You're confusing the webrtc application (what runs in the browser) with the= webrtc implementation (the browser itself). Optional NDATA makes the brows= er *more* complex, since it has to expose API surface to let the applicatio= n choose whether or not to offer NDATA, and it has to have code to decide w= hether or not to offer NDATA. I am talking about 2 items: 1. Making NDATA a MUST data channel draft? I could be wrong, but I tho= ught this is the main discussion point in this thread! This is a burden on = non-webrtc users of data channel. My understanding is data channels are mea= nt to be used by non-webrtc as a general protocol. Please correct me if my = understanding is not correct. Your understanding may be right or wrong, but it's different from mine. Data channels are created to be useful for WebRTC. That's their purpose in = being created, so WebRTC requirements take precedence over all other requir= ements. IMHO, I don't think that is how IETF worked; you produce something which is= generally useful than very specific to one particular use case without giv= ing up on too much for the original purpose. In fact, WebRTC is a huge bene= ficiary of it!! IMHO, making data channels transport a generic mechanism is= part of that process. NDATA makes them more useful for WebRTC (or, as Martin put it, "without NDA= TA, they're not fit for purpose"). Optional NDATA makes things more complex for WebRTC. Therefore, seen from a WebRTC viewpoint, speaking in the RTCWEB WG, I think= NDATA should be mandatory. This is related to webrtc vs. non-webrtc use of data channels. To give data= channels independence (sorry, I did not mean in a dramatic way :)) from we= brtc, can we make data channel drafts generic and compliancy aspects of it = into a webrtc specific section/draft; this (separate draft) is how it is do= ne for RTP transport. Such webrtc compliance for data channels can be part = of the same data channel draft but a new webrtc specific section or in a ne= w/existing webrtc specific draft (webrtc/data-channel overview draft). Simi= larly CLUE specific compliance can be in a separate section of the data cha= nnel draft. 2. Making NDATA a MUST for webrtc clients? I am not just talking about= browser, but non-browser based native/hybrid webrtc clients (e.g. a thin w= ebrtc client on a cable set top box) as well. Browsers can implement it as = a MUST clause, no one is stopping that. But why mandate a set top box (or a= n IoT device) implement NDATA when it just wants to use a single data chann= el only?! Let's take an example: We keep NDATA a MUST. During SCTP setup, if NDATA is= not supported at the peer then will the SCTP setup be abandoned? If the SC= TP association is not abandoned then there is no point in making it a MUST = where as in real practice it is not enforced as a MUST. In general, when an application connects to something that does not conform= to the spec for the protocol he's using, "all bets are off". Implementations are free to handle this situation whatever way they want. This item is specific to data channel requirements for webrtc use. If a req= uirement is a MUST then how can it be implementation specific? Then why put= a requirement as MUST but still allow implementations to have different be= havior? Note: So far, I've seen *zero* evidence that the burden of implementing NDA= TA is significantly higher than the total effort spent in writing updates o= n this thread. For 90+% of all implementors, not implementing NDATA is a la= rger effort than implementing it, because the libraries they use will suppo= rt it, so they have to take action to take it out. The 90% can then always support NDATA... no issue with that. But why make i= t a burden for rest of the 10% (these are the ones who may be constrained b= y various resources)? IMHO, we don't add MORE work for an implementation ju= st because it already has LOTs of work to do anyway! It should be other way= around, since there is so much stuff mandatory already why not go easy on = the stuff which may not be needed by some applications!!? BR Raju --_000_E1FE4C082A89A246A11D7F32A95A17828E5F6685US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see my comments in= line.

 <= /p>

From: Harald Alvestrand [m= ailto:harald@alvestrand.no]
Sent: Tuesday, October 28, 2014 8:27 AM

From: Harald Alvestra= nd [mailto:harald@alvestrand.no= ]
Sent: Monday, October 27, 2014 5:03 PM

On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju)= wrote:

+1 to make N-DATA optional.

 

Data channel provides a robust generic peer to peer = communication channel. So, one can see that data channel may be used under = non-webrtc contexts (like as in CLUE) as a general transport or as a replac= ement of native to SCTP to traverse firewalls. IMHO, majority of these use cases:

a. May just involve a single data channel (with poss= ible multiplexing on top of it)

b. And may not use the DCEP either (both ends could = assume same data channel stream id, this is similar to SCTP PPIDs).

We already made DCEP(b) as optional.

 

If an app is using just a single data channel then t= here is no real benefit in using N-DATA. Then why not make it optional? Als= o, as already pointed out, making it optional won’t break interop as = it is still negotiated during SCTP setup time anyway.


Negotiation means that transport initiator gets to choose whether to use it= or not.
This means that a responder has no choice in the matter.

In the situation where the responder knows better than the initiator what t= he usage is going to be, this is problematic.

<Raju>

IMHO, it is not just the responder knowing “be= tter” which makes a scenario work, rather both have to agree on it. F= or example, if responder wants to have multiple data channels is no good if= the originator does not want to support (CLUE use of data channels is an example of it). That’s why, in most cases= I know it is the originator who offers capabilities and terminator gets to= choose.

</Raju>

 

I would like to point out that there will be some we= brtc applications which might just use one webrtc data channel for simplici= ty (and may use some multiplexing of different types of msgs/objects on top= of it) or one is just sufficient as the app does not send/recv huge chunks of data. So, N-DATA isn’t = needed for such webrtc clients either. Then why add burden to such webrtc i= mplementations!?


You're confusing the webrtc application (what runs in the browser) with the= webrtc implementation (the browser itself). Optional NDATA makes the brows= er *more* complex, since it has to expose API surface to let the applicatio= n choose whether or not to offer NDATA, and it has to have code to decide whether or not to offer NDATA.

<Raju>

I am talking about 2 items:

1.      Making NDATA a MUST data channel draft? I could be = wrong, but I thought this is the main discussion point in this thread! This= is a burden on non-webrtc users of data channel. My understanding is data = channels are meant to be used by non-webrtc as a general protocol. Please correct me if my understanding is= not correct.


Your understanding may be right or wrong, but it's different from mine.

Data channels are created to be useful for WebRTC. That's their purpose in = being created, so WebRTC requirements take precedence over all other requir= ements.

<Raju2><= /o:p>

IMHO, I don’t th= ink that is how IETF worked; you produce something which is generally usefu= l than very specific to one particular use case without giving up on too mu= ch for the original purpose. In fact, WebRTC is a huge beneficiary of it!! IMHO, making data channels transport a gener= ic mechanism is part of that process.

</Raju2>

NDATA makes them more useful for WebRTC (or, as Martin put it, "withou= t NDATA, they're not fit for purpose").

Optional NDATA makes things more complex for WebRTC.

Therefore, seen from a WebRTC viewpoint, speaking in the RTCWEB WG, I think= NDATA should be mandatory.=

<Raju2><= /o:p>

This is related to web= rtc vs. non-webrtc use of data channels. To give data channels independence= (sorry, I did not mean in a dramatic way J) from webrtc, can we make data channel drafts generi= c and compliancy aspects of it into a webrtc specific section/draft; this (= separate draft) is how it is done for RTP transport. Such webrtc compliance for data channels can be part of the= same data channel draft but a new webrtc specific section or in a new/exis= ting webrtc specific draft (webrtc/data-channel overview draft). Similarly = CLUE specific compliance can be in a separate section of the data channel draft.

</Raju2>


2.      Making NDATA a MUST for webrtc clients? I am not ju= st talking about browser, but non-browser based native/hybrid webrtc client= s (e.g. a thin webrtc client on a cable set top box) as well. Browsers can = implement it as a MUST clause, no one is stopping that. But why mandate a set top box (or an IoT device) imp= lement NDATA when it just wants to use a single data channel only?!

Let’s take an example: We keep NDATA a = MUST. During SCTP setup, if NDATA is not supported at the peer then will th= e SCTP setup be abandoned? If the SCTP association is not abandoned then th= ere is no point in making it a MUST where as in real practice it is not enforced as a MUST.


In general, when an application connects to something that does not conform= to the spec for the protocol he's using, "all bets are off".

Implementations are free to handle this situation whatever way they want.

<Raju2><= /o:p>

This item is specif= ic to data channel requirements for webrtc use. If a requirement is a MUST = then how can it be implementation specific? Then why put a requirement as MUST but still allow implementations to have different be= havior?

</Raju2>=


Note: So far, I've seen *zero* evidence that the burden of implementing NDA= TA is significantly higher than the total effort spent in writing updates o= n this thread. For 90+% of all implementors, not implementing NDATA is = a larger effort than implementing it, because the libraries they use will support it, so they have to take actio= n to take it out.

<Raju2><= /o:p>

The 90% can then al= ways support NDATA… no issue with that. But why make it a burden for = rest of the 10% (these are the ones who may be constrained by various resources)? IMHO, we don’t add MORE work for an implementati= on just because it already has LOTs of work to do anyway! It should be othe= r way around, since there is so much stuff mandatory already why not go eas= y on the stuff which may not be needed by some applications!!?

</Raju2>=

 

BR

Raju=

--_000_E1FE4C082A89A246A11D7F32A95A17828E5F6685US70UWXCHMBA02z_-- From nobody Tue Oct 28 10:56:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90101AC39E for ; Tue, 28 Oct 2014 10:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4okE_YenDOp for ; Tue, 28 Oct 2014 10:55:55 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543371A914D for ; Tue, 28 Oct 2014 10:53:22 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-49-544fd80f5563 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E5.E2.24955.F08DF445; Tue, 28 Oct 2014 18:53:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 18:53:19 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3////5gA///tr8CAAFjuAP//7KkQgAAtDgCAABO7S///8JGA//7IDGD//YqpAP/6+gaQ//X5SwD/68m9gA== Date: Tue, 28 Oct 2014 17:53:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4D14F7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3Rlfghn+IwamDIhYrXp9jt7jYtITR Yu2/dnYHZo8lS34yeWxo2cHkMflxG3MAcxSXTUpqTmZZapG+XQJXRu/9A8wFv1wr7n34z9zA 2ODSxcjJISFgIjHl8VxGCFtM4sK99WxdjFwcQgJHGCVa5t9nhnCWADnvZ7B0MXJwsAlYSHT/ 0wZpEBFQkPj15wQLiM0sECOx6vp1ZhBbWMBB4uzOSewQNY4SbW/PM0HYdRIzD3SC1bAIqErs 23GbGWQkr4CvxO/fThCrvrNKbDs4F2wVp0CgxP0LQSDljEC3fT+1hglilbjErSfzmSBuFpBY suc8M4QtKvHy8T9WCFtJYsX2S4wQ9fkS2yaeBLN5BQQlTs58wjKBUXQWklGzkJTNQlI2C+gK ZgFNifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQT IzD+Dm75rbqD8fIbx0OMAhyMSjy8G9j8Q4RYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1 ILUovqg0J7X4ECMTB6dUA6Ns+8WOthj7H+ve67tt4YneJaxuE+kWzrxFUPf+oRk/vN97xe51 1PqxYYeTQIn7p32Mpr0LQtn3CUUpFEjtPLLvU7Eso6KLROhfAe8Vm8U2+C+++EXmRrP0jsqc NOUyLdvfzhY9a07rFGvl9qjO4Dzwf93FGa2SYcxa7+sLf0+z7AuP5EjuVmIpzkg01GIuKk4E ALbeiN6gAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dYGggzY1QT4tUG1b8b3zJuVT4W0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 17:55:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4D14F7ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj4+PiBJIGFtIG5vdCBzdWdnZXN0aW5nIGRpZmZlcmVudCBmbGF2b3JzIC0gSSBhbSBz dWdnZXN0aW5nIHRvIG1ha2UgdGhlIHVzYWdlIG9mDQo+Pj4gaW50ZXJsZWF2aW5nIG9wdGlvbmFs LiBPdGhlciBTQ1RQIGZlYXR1cmVzIGFyZSBhbHNvIG9wdGlvbmFsIChpbmNsdWRpbmcgcmVsaWFi aWxpdHksIG9yZGVyaW5nIGV0YykuDQo+Pj4NCj4+PiBXaGVyZSBhcmUgdGhlc2UgdGhpbmdzIG9w dGlvbmFsPyBBY2NvcmRpbmcgdG8NCj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsLTEyI3NlY3Rpb24NCj4+PiAtNi4xIGFuIGltcGxl bWVudGF0aW9uIE1VU1QgaW1wbGVtZW50IFBSLVNDVFAgYW5kIHRoZSBzdXBwb3J0IG9mIHRoZQ0K Pj4+IEZPUldBUkQtVFNOIGNodW5rIHdpbGwgYmUgbmVnb3RpYXRlZCBzaW1pbGFyIHRvIHRoZSBO REFUQSBjaHVuay4gSSBkb24ndCBzZWUgYSBkaWZmZXJlbmNlLCBlc3BlY2lhbGx5IG5vdCBpZiB3 ZSBtb3ZlIHRvIE1VU1Qgc3VwcG9ydCBOREFUQS4NCj4+DQo+PiBGb3IgZXhhbXBsZSwgc2VjdGlv biA2LjEgc2F5czoNCj4+DQo+PiAgICAgICJUaGUgcGFydGlhbCByZWxpYWJpbGl0eSBleHRlbnNp b24gZGVmaW5lZCBpbiBbUkZDMzc1OF0gTVVTVCBiZSBzdXBwb3J0ZWQuIg0KPj4NCj4+IEhvd2V2 ZXIsIGluIENMVUUgd2Ugc2F5IHRoYXQgYSBDTFVFIGVudGl0eSBNVVNUIE5PVCAqdXNlKiB0aGUg ZXh0ZW5zaW9uLCBhcyBhbGwgQ0xVRSBtZXNzYWdlcyBhcmUgcmVxdWlyZWQgdG8gYmUgc2VudCBy ZWxpYWJseS4NCj4NCj4gVGhhdCBpcyBPSy4gSG93ZXZlciwgc3VwcG9ydCBmb3IgUFItU0NUUCBN VVNUIGJlIHRoZXJlIGFuZCBpdCB3aWxsIGJlIG5lZ290aWF0ZWQuIFlvdSBqdXN0IG5ldmVyIHNl bmQgYSBtZXNzYWdlIHdpdGggcGFydGlhbCByZWxpYWJpbGl0eS4gQXQgbGVhc3QgdGhpcyBpcyBt eSB1bmRlcnN0YW5kaW5nLi4uDQoNClNvLCBjYW4gdGhlIHNhbWUgYmUgZG9uZSBmb3IgaW50ZXJs ZWF2aW5nPyBJLmUuIHRoZSBzdXBwb3J0IE1VU1QgYmUgdGhlcmUsIGJ1dCBlLmcuIENMVUUgZW50 aXRpZXMgY2FuIGNob29zZSBub3QgdG8gdXNlIGl0Pw0KDQpOb3RlIHRoYXQgbXkgaXNzdWUgaXMg bm90IGFib3V0IHN1cHBvcnQsIGl0J3MgYWJvdXQgdXNhZ2UgOikNCg0KV2hhdCByZXNvdXJjZSBp cyBiZWluZyBjb25zZXJ2ZWQgYnkgbm90IGp1c3QgcmVxdWlyaW5nIGl0Pw0KDQpJIGRvbuKAmXQg a25vdy4gVGhlIHRhc2sgaXMgdG8gZmlndXJlIG91dCB3aGV0aGVyIHRoZXJlIGFyZSB0ZWNobmlj YWwgcmVhc29ucyB0byBtYW5kYXRlIHVzYWdlIG9mIGNlcnRhaW4gU0NUUCBmZWF0dXJlcyBmb3Ig Q0xVRS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== --_000_7594FB04B1934943A5C02806D1A2204B1D4D14F7ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0 OyZndDsgSSBhbSBub3Qgc3VnZ2VzdGluZyBkaWZmZXJlbnQgZmxhdm9ycyAtIEkgYW0gc3VnZ2Vz dGluZyB0byBtYWtlIHRoZSB1c2FnZSBvZjxicj4NCiZndDsmZ3Q7Jmd0OyBpbnRlcmxlYXZpbmcg b3B0aW9uYWwuIE90aGVyIFNDVFAgZmVhdHVyZXMgYXJlIGFsc28gb3B0aW9uYWwgKGluY2x1ZGlu ZyByZWxpYWJpbGl0eSwgb3JkZXJpbmcgZXRjKS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgV2hlcmUgYXJlIHRoZXNlIHRoaW5ncyBvcHRpb25hbD8gQWNjb3JkaW5nIHRvPGJy Pg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXJ0Y3dlYi1kYXRhLWNoYW5uZWwtMTIjc2VjdGlvbiIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5l bC0xMiNzZWN0aW9uPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyAtNi4xIGFuIGltcGxlbWVudGF0aW9u IE1VU1QgaW1wbGVtZW50IFBSLVNDVFAgYW5kIHRoZSBzdXBwb3J0IG9mIHRoZTxicj4NCiZndDsm Z3Q7Jmd0OyBGT1JXQVJELVRTTiBjaHVuayB3aWxsIGJlIG5lZ290aWF0ZWQgc2ltaWxhciB0byB0 aGUgTkRBVEEgY2h1bmsuIEkgZG9uJ3Qgc2VlIGEgZGlmZmVyZW5jZSwgZXNwZWNpYWxseSBub3Qg aWYgd2UgbW92ZSB0byBNVVNUIHN1cHBvcnQgTkRBVEEuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBGb3IgZXhhbXBsZSwgc2VjdGlvbiA2LjEgc2F5czo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7VGhlIHBhcnRpYWwgcmVsaWFiaWxpdHkg ZXh0ZW5zaW9uIGRlZmluZWQgaW4gW1JGQzM3NThdIE1VU1QgYmUgc3VwcG9ydGVkLiZxdW90Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSG93ZXZlciwgaW4gQ0xVRSB3ZSBzYXkgdGhhdCBh IENMVUUgZW50aXR5IE1VU1QgTk9UICp1c2UqIHRoZSBleHRlbnNpb24sIGFzIGFsbCBDTFVFIG1l c3NhZ2VzIGFyZSByZXF1aXJlZCB0byBiZSBzZW50IHJlbGlhYmx5Ljxicj4NCiZndDs8YnI+DQom Z3Q7IFRoYXQgaXMgT0suIEhvd2V2ZXIsIHN1cHBvcnQgZm9yIFBSLVNDVFAgTVVTVCBiZSB0aGVy ZSBhbmQgaXQgd2lsbCBiZSBuZWdvdGlhdGVkLiBZb3UganVzdCBuZXZlciBzZW5kIGEgbWVzc2Fn ZSB3aXRoIHBhcnRpYWwgcmVsaWFiaWxpdHkuIEF0IGxlYXN0IHRoaXMgaXMgbXkgdW5kZXJzdGFu ZGluZy4uLjxicj4NCjxicj4NClNvLCBjYW4gdGhlIHNhbWUgYmUgZG9uZSBmb3IgaW50ZXJsZWF2 aW5nPyBJLmUuIHRoZSBzdXBwb3J0IE1VU1QgYmUgdGhlcmUsIGJ1dCBlLmcuIENMVUUgZW50aXRp ZXMgY2FuIGNob29zZSBub3QgdG8gdXNlIGl0Pzxicj4NCjxicj4NCk5vdGUgdGhhdCBteSBpc3N1 ZSBpcyBub3QgYWJvdXQgc3VwcG9ydCwgaXQncyBhYm91dCB1c2FnZSA6KTxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCByZXNv dXJjZSBpcyBiZWluZyBjb25zZXJ2ZWQgYnkgbm90IGp1c3QgcmVxdWlyaW5nIGl0PzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6cmVkIj5JIGRvbuKAmXQga25vdy4gVGhlIHRhc2sgaXMgdG8gZmlndXJlIG91dCB3aGV0 aGVyIHRoZXJlIGFyZQ0KPGI+dGVjaG5pY2FsPC9iPiByZWFzb25zIHRvIG1hbmRhdGUgdXNhZ2Ug b2YgY2VydGFpbiBTQ1RQIGZlYXR1cmVzIGZvciBDTFVFLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpyZWQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6cmVkIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4D14F7ESESSMB209erics_-- From nobody Tue Oct 28 13:17:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D241ACF58 for ; Tue, 28 Oct 2014 13:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8tIVi_jHovv for ; Tue, 28 Oct 2014 13:17:51 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F11E1ACE15 for ; Tue, 28 Oct 2014 13:13:03 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-04v.sys.comcast.net with comcast id 8kAb1p00557bBgG01kD36F; Tue, 28 Oct 2014 20:13:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-13v.sys.comcast.net with comcast id 8kD21p00K3Ge9ey01kD2Du; Tue, 28 Oct 2014 20:13:03 +0000 Message-ID: <544FF8CE.5070304@alum.mit.edu> Date: Tue, 28 Oct 2014 16:13:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414527183; bh=cqsrqcX9uDrMJcuCU9f5H3XQgMHW7oRwqmqbhL1ugDI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TkexlvArZmK7DwKfeurYQsYFMJghVh/F1iSKVIll8fJ3cUzMS2gkX0R8UwnIsE1B5 w5auY0GzRD01ik7ayxmfAv1U1F8x0hogGiDG3REw4XgoS0yrSwUa7GzgH2XQGaGmDC zMQWy5QONx5I0kZiO9bBk7hfl42GLFifkJNnB6GLADQhYPQEFDzn9FdNZK7+DvIFwF 1ZBKkrDxyN/Lmlua3iWBa7nsK8wr96SCzDj69t7So9nAK5mn4jrLXzUghiZ2uZaSfU QOKBUcLiu3D2zimR9dtNhC1WSPzf2UFHhn37mRSv12sw5ywn/gHWDr94nliAZSxIem OQNS+daY1c+xQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FSqfBLxgPT9TWCCNsW5t0p88vWM Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 20:17:53 -0000 (This thread has gotten long, and its hard to figure where to jump in. I'm just replying to the last message I see, but am commenting on the thread in total.) Regarding data channels being webrtc-specific: I don't see it that way. Webrtc has opened up restricted communication among browsers. If you want to talk to a browser, you have few choices, and this is the one that is "general purpose". So any application that sometimes might need to run in a browser is a likely candidate for data channels. And then, when non-browser versions of that app are talking to one another, it will be most practical to use the same mechanism. That is why CLUE is using data channels - even if we think that *most* of the endpoints won't be in browsers. Regarding NDATA: ISTM that SCTP just screwed up in not including the NDATA features in the base protocol. Going forward, it always should be included in new implementations. Since data channels are being defined after NDATA, it is perfectly reasonable for data channels to require NDATA support. IIUC, while NDATA allows fragmentation to avoid head of line blocking, that doesn't mean the messages will be fragmented unnecessarily. If you are only using one channel I *think* it likely that even a large message won't be fragmented. So it will be harmless insurance. Christer said that since CLUE only needs one data channel there is no need for NDATA. Someone specifying BFCP over data channel might reach a similar conclusion for it. But there is nothing to prevent an application that implements both CLUE and BFCP. Independently they wouldn't need NDATA, but together they would. So I am in favor of making NDATA mandatory to implement, offer, and accept for data channels. But I would still like the data channel spec to acknowledge that, while webrtc is a *very* important client, that the protocol solely for webrtc. And with that in mind I would like to see "webrtc" removed from the name of the protocol. (E.g., in the SDP m-line.) Thanks, Paul On 10/28/14 1:53 PM, Christer Holmberg wrote: > Hi, > > >>> I am not suggesting different flavors - I am suggesting to make > the usage of > >>> interleaving optional. Other SCTP features are also optional > (including reliability, ordering etc). > >>> > >>> Where are these things optional? According to > >>> > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section > >>> -6.1 an implementation MUST implement PR-SCTP and the support > of the > >>> FORWARD-TSN chunk will be negotiated similar to the NDATA > chunk. I don't see a difference, especially not if we move to MUST > support NDATA. > >> > >> For example, section 6.1 says: > >> > >> "The partial reliability extension defined in [RFC3758] > MUST be supported." > >> > >> However, in CLUE we say that a CLUE entity MUST NOT *use* the > extension, as all CLUE messages are required to be sent reliably. > > > > That is OK. However, support for PR-SCTP MUST be there and it > will be negotiated. You just never send a message with partial > reliability. At least this is my understanding... > > So, can the same be done for interleaving? I.e. the support MUST be > there, but e.g. CLUE entities can choose not to use it? > > Note that my issue is not about support, it's about usage :) > > What resource is being conserved by not just requiring it? > > I don’t know. The task is to figure out whether there are *technical* > reasons to mandate usage of certain SCTP features for CLUE. > > Regards, > > Christer > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Oct 28 13:53:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3251A90AE for ; Tue, 28 Oct 2014 13:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5a6vY_nMAKY for ; Tue, 28 Oct 2014 13:52:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319161A90A4 for ; Tue, 28 Oct 2014 13:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3525; q=dns/txt; s=iport; t=1414529578; x=1415739178; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2BVewdouMsNgdq8QfU9a8uTzxV1BLrTQlOc9wj5bsls=; b=krEVzJMG9oDhVW28Zc3AdlW1izP4Co/2mhEskrwiCxAhNILLw8/CUIJc TCaIoynC+41k/RARh8ejkxGzu26A+7+DMN5i/zbMOpeDg7oimSOPoD+P6 IebvUGvD5sjIQluq+L1mHAr4CrILV55ClqaneXmaMmd4szlheFl3cDRxq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAM4AUFStJV2c/2dsb2JhbABcgkhGgTDWDgKBIRYBAQEBAX2EAwEBAwF5BQsCAQgEQjIlAgQBDYg9CccSAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5EJB4RLBZILi12WNoF+IIFagjSBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,804,1406592000"; d="scan'208,217";a="367267288" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 28 Oct 2014 20:52:57 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9SKqvse005187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 20:52:57 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.159]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 15:52:57 -0500 From: "Mo Zanaty (mzanaty)" To: Christer Holmberg , Eric Rescorla , Michael Tuexen , "Harald Alvestrand" Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: AQHP8vEmqS2/U13JNkqofeKaZ1Gl3g== Date: Tue, 28 Oct 2014 20:52:56 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.81.3.32] Content-Type: multipart/alternative; boundary="_000_D07572143D0B4mzanatyciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ejyOr_Mhwh9U8iS60OEaNB9Akhg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 20:53:01 -0000 --_000_D07572143D0B4mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > What resource is being conserved by not just requiring it? 8 bytes per packet (for MID+FSN). Michael, the current NDATA draft requires it to be used for all messages if= negotiated. Can=92t this be relaxed / optimized to use it for all *fragmen= ted* messages but use DATA for non-fragmented messages to avoid the 8 byte = overhead for small messages (like game telemetry/control, an often cited us= e of data channels). The current NDATA draft also says you can=92t interleave fragmented message= s in a stream, so head of line blocking remains for all fragmented messages= , while only small non-fragmented messages can avoid it. This dilutes the u= tility of NDATA, perhaps enough to make apps that really care about head of= line blocking to implement their own app layer fragmentation with messages= well below common MTUs, hence defeating NDATA. Can=92t this also be relaxe= d since MID is part of the NDATA extra header? If those two issues are resolved, I see no argument against making NDATA a = MUST in data channels. Mo PS. Some believe data channels will be more widely used than WebRTC media (= webtorrent, etc.), so it does make sense to consider the desirable properti= es of a general peer-to-peer transport, and drop the WebRTC prefix when tal= king about data channels. --_000_D07572143D0B4mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
> What resource is being conserved by not just requiring it?

8 bytes per packet (for MID+FSN).

Michael, the current NDATA draft requires it to be used for all messag= es if negotiated. Can=92t this be relaxed / optimized to use it for all *fr= agmented* messages but use DATA for non-fragmented messages to avoid the 8 = byte overhead for small messages (like game telemetry/control, an often cited use of data channels).

The current NDATA draft also says you can=92t interleave fragmented me= ssages in a stream, so head of line blocking remains for all fragmented mes= sages, while only small non-fragmented messages can avoid it. This dilutes = the utility of NDATA, perhaps enough to make apps that really care about head of line blocking to implement the= ir own app layer fragmentation with messages well below common MTUs, hence = defeating NDATA. Can=92t this also be relaxed since MID is part of the NDAT= A extra header?

If those two issues are resolved, I see no argument against making NDA= TA a MUST in data channels.

Mo

PS. Some believe data channels will be more widely used than WebRTC me= dia (webtorrent, etc.), so it does make sense to consider the desirable pro= perties of a general peer-to-peer transport, and drop the WebRTC prefix whe= n talking about data channels.
--_000_D07572143D0B4mzanatyciscocom_-- From nobody Tue Oct 28 14:11:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB761ACFBD for ; Tue, 28 Oct 2014 14:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuiSHREPb_Bs for ; Tue, 28 Oct 2014 14:11:44 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FD61ACFBA for ; Tue, 28 Oct 2014 14:11:44 -0700 (PDT) Received: from [192.168.1.200] (p508F31C9.dip0.t-ipconnect.de [80.143.49.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 622EC1C1050F4; Tue, 28 Oct 2014 22:11:40 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Tue, 28 Oct 2014 22:11:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> To: "Mo Zanaty (mzanaty)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7WbZYeeEbqYGrOIhr59wdhZOB0o Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 21:11:46 -0000 On 28 Oct 2014, at 21:52, Mo Zanaty (mzanaty) wrote: > > What resource is being conserved by not just requiring it? >=20 > 8 bytes per packet (for MID+FSN). >=20 > Michael, the current NDATA draft requires it to be used for all = messages if negotiated. Can=92t this be relaxed / optimized to use it = for all *fragmented* messages but use DATA for non-fragmented messages = to avoid the 8 byte overhead for small messages (like game = telemetry/control, an often cited use of data channels). You can bring this up at the tsvwg mailing list. However, we normally do = not optimize for byte saving... Mixing both makes the processing harder... Maybe we can use a bit in the flags = to indicate if the additional fields are there... >=20 > The current NDATA draft also says you can=92t interleave fragmented = messages in a stream, so head of line blocking remains for all = fragmented messages, while only small non-fragmented messages can avoid = it. This dilutes the utility of NDATA, perhaps enough to make apps that = really care about head of line blocking to implement their own app layer = fragmentation with messages well below common MTUs, hence defeating = NDATA. Can=92t this also be relaxed since MID is part of the NDATA extra = header? This would only make sense for messages marked as unordered... For = ordered it doesn't make sense. >=20 > If those two issues are resolved, I see no argument against making = NDATA a MUST in data channels. Please let us discuss NDATA issues on the tsvwg mailing list... Best regards Michael >=20 > Mo >=20 > PS. Some believe data channels will be more widely used than WebRTC = media (webtorrent, etc.), so it does make sense to consider the = desirable properties of a general peer-to-peer transport, and drop the = WebRTC prefix when talking about data channels. From nobody Tue Oct 28 15:14:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1591AD3A0 for ; Tue, 28 Oct 2014 15:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHGyXtB88Tmf for ; Tue, 28 Oct 2014 15:14:35 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7601AD3A2 for ; Tue, 28 Oct 2014 15:14:22 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-05v.sys.comcast.net with comcast id 8mDt1p0055FMDhs01mELel; Tue, 28 Oct 2014 22:14:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id 8mEK1p00e3Ge9ey01mELp3; Tue, 28 Oct 2014 22:14:20 +0000 Message-ID: <5450153B.8000808@alum.mit.edu> Date: Tue, 28 Oct 2014 18:14:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> <544FF8CE.5070304@alum.mit.edu> In-Reply-To: <544FF8CE.5070304@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414534460; bh=9EsUru1XY99UOOjRgbgPH9p0Px4Izs+e9Nd9vKgphKA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HsLXcUdWDgDStiwBaJs97I+83yFVFCWo7AzvTllZ+kBrIKsiIuLRhqrGIyhCddvzt TiinQrKhABTA3tKfh+XRFhPJV//nuJ1buBZ8N+sCcBA0DT8M2ltdeJs4/vKuvyfbzf SR1aQq+YfFcxfwd1ZXn6PBLbeNgFdU9CPZ2TcGSy2d5bw3GmANXiFW56Udl0bNBEfj zg+GQGE9SeA9pzwHOnnVJ+kqzq1odKISaQjeGzvK9ZgcUR7NIPQmshwWMpDGv1JsHJ dEIJB7cmtEIOwZ4Zc70U4lHZ9opea9yalfDJ1lhYhqr4bBqUAH46GQ/Fr3rTfaxH1H rNO8fHAHvbRWw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2Ytya6fZfW8zYG_okO_Nq-VHC4E Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 22:14:37 -0000 Mary pointed out an important typo in this message. Correction inline. On 10/28/14 4:13 PM, Paul Kyzivat wrote: > (This thread has gotten long, and its hard to figure where to jump in. > I'm just replying to the last message I see, but am commenting on the > thread in total.) > > Regarding data channels being webrtc-specific: > > I don't see it that way. Webrtc has opened up restricted communication > among browsers. If you want to talk to a browser, you have few choices, > and this is the one that is "general purpose". So any application that > sometimes might need to run in a browser is a likely candidate for data > channels. And then, when non-browser versions of that app are talking to > one another, it will be most practical to use the same mechanism. > > That is why CLUE is using data channels - even if we think that *most* > of the endpoints won't be in browsers. > > Regarding NDATA: > > ISTM that SCTP just screwed up in not including the NDATA features in > the base protocol. Going forward, it always should be included in new > implementations. Since data channels are being defined after NDATA, it > is perfectly reasonable for data channels to require NDATA support. > > IIUC, while NDATA allows fragmentation to avoid head of line blocking, > that doesn't mean the messages will be fragmented unnecessarily. If you > are only using one channel I *think* it likely that even a large message > won't be fragmented. So it will be harmless insurance. > > Christer said that since CLUE only needs one data channel there is no > need for NDATA. Someone specifying BFCP over data channel might reach a > similar conclusion for it. But there is nothing to prevent an > application that implements both CLUE and BFCP. Independently they > wouldn't need NDATA, but together they would. > > So I am in favor of making NDATA mandatory to implement, offer, and > accept for data channels. > > But I would still like the data channel spec to acknowledge that, while > webrtc is a *very* important client, that the protocol solely for > webrtc. And with that in mind I would like to see "webrtc" removed from > the name of the protocol. (E.g., in the SDP m-line.) What I meant to say in the last paragraph is: But I would still like the data channel spec to acknowledge that, while webrtc is a *very* important client, that the protocol *is not* solely for webrtc. And with that in mind I would like to see "webrtc" removed from the name of the protocol. (E.g., in the SDP m-line.) Thanks, Paul > On 10/28/14 1:53 PM, Christer Holmberg wrote: >> Hi, >> >> >>> I am not suggesting different flavors - I am suggesting to make >> the usage of >> >>> interleaving optional. Other SCTP features are also optional >> (including reliability, ordering etc). >> >>> >> >>> Where are these things optional? According to >> >>> >> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section >> >>> -6.1 an implementation MUST implement PR-SCTP and the support >> of the >> >>> FORWARD-TSN chunk will be negotiated similar to the NDATA >> chunk. I don't see a difference, especially not if we move to MUST >> support NDATA. >> >> >> >> For example, section 6.1 says: >> >> >> >> "The partial reliability extension defined in [RFC3758] >> MUST be supported." >> >> >> >> However, in CLUE we say that a CLUE entity MUST NOT *use* the >> extension, as all CLUE messages are required to be sent reliably. >> > >> > That is OK. However, support for PR-SCTP MUST be there and it >> will be negotiated. You just never send a message with partial >> reliability. At least this is my understanding... >> >> So, can the same be done for interleaving? I.e. the support MUST be >> there, but e.g. CLUE entities can choose not to use it? >> >> Note that my issue is not about support, it's about usage :) >> >> What resource is being conserved by not just requiring it? >> >> I don’t know. The task is to figure out whether there are *technical* >> reasons to mandate usage of certain SCTP features for CLUE. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> 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 nobody Tue Oct 28 15:28:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358B81A0081 for ; Tue, 28 Oct 2014 15:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHYhUK60rCpt for ; Tue, 28 Oct 2014 15:28:54 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E583D1A0022 for ; Tue, 28 Oct 2014 15:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2576; q=dns/txt; s=iport; t=1414535334; x=1415744934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xEWXVZ/4sJpgIWUTnKgzyAMJ+b3iFLYbKwqNvwgrWwM=; b=CF894BZuigw2PiVBF1bHVbse5w9/2/+AJsimfMOY0Gu0gORnpUzXD4iW 8Ka7dDvI1MnkljimHSHgTh9mMqSm0ISsVh3dNtdSX0Z9h6B8nfUSMFufi hhiqGQ3ajCojUDtKyjR8zNTdmRxvqaR9GS8sgYpePl3AxCjF/TZXYtQ50 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAD8YUFStJV2a/2dsb2JhbABcgw6BLNYTAoEjFgEBAQEBfYQDAQEDAW4LEAIBCEYyJQIEDgWIOAnGDgEBAQEBAQEBAQEBAQEBAQEBAQEZkFYzB4MtgR4FkguLXYExg0mRPIF+IIFabAGCSgEBAQ X-IronPort-AV: E=Sophos;i="5.04,805,1406592000"; d="scan'208";a="91184238" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 28 Oct 2014 22:28:54 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9SMSrJT015174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 22:28:53 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.159]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 17:28:53 -0500 From: "Mo Zanaty (mzanaty)" To: Michael Tuexen Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: AQHP8vEmqS2/U13JNkqofeKaZ1Gl3pxGVXUA///BxDI= Date: Tue, 28 Oct 2014 22:28:52 +0000 Message-ID: <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> , <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> In-Reply-To: <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ugkohpPwWDjZRYw6_zqnb-QMqPs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 22:28:56 -0000 On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" wrote: On 28 Oct 2014, at 21:52, Mo Zanaty (mzanaty) wrote: >> What resource is being conserved by not just requiring it? >=20 > 8 bytes per packet (for MID+FSN). >=20 > Michael, the current NDATA draft requires it to be used for all messages = if negotiated. Can=92t this be relaxed / optimized to use it for all *fragm= ented* messages but use DATA for non-fragmented messages to avoid the 8 byt= e overhead for small messages (like game telemetry/control, an often cited = use of data channels). You can bring this up at the tsvwg mailing list. Mo: Will do. However, we normally do not optimize for byte saving... Mixing both makes the processing harder... Maybe we can use a bit in the flags to = indicate if the additional fields are there... Mo: Type should already be enough without flags. >=20 > The current NDATA draft also says you can=92t interleave fragmented messa= ges in a stream, so head of line blocking remains for all fragmented messag= es, while only small non-fragmented messages can avoid it. This dilutes the= utility of NDATA, perhaps enough to make apps that really care about head = of line blocking to implement their own app layer fragmentation with messag= es well below common MTUs, hence defeating NDATA. Can=92t this also be rela= xed since MID is part of the NDATA extra header? This would only make sense for messages marked as unordered... For ordered = it doesn't make sense. Mo: The restriction applies to unordered as well as ordered. Even for order= ed, it does make sense to avoid head of line blocking at the sender.=20 >=20 > If those two issues are resolved, I see no argument against making NDATA = a MUST in data channels. Please let us discuss NDATA issues on the tsvwg mailing list... Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its benefits= outweigh its costs. The current draft does not pass that bar for me. If my= app cares about HOL blocking, NDATA is not very useful, so my app must int= ernally fragment, hence NDATA actually becomes harmful (8 bytes closer to e= xceeding MTU, forcing SCTP fragments and hence risking HOL blocking). Best regards Michael >=20 > Mo >=20 > PS. Some believe data channels will be more widely used than WebRTC media= (webtorrent, etc.), so it does make sense to consider the desirable proper= ties of a general peer-to-peer transport, and drop the WebRTC prefix when t= alking about data channels. From nobody Tue Oct 28 15:54:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CF91A0177 for ; Tue, 28 Oct 2014 15:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEF5i3bVxNZr for ; Tue, 28 Oct 2014 15:54:43 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721D91A00A9 for ; Tue, 28 Oct 2014 15:54:43 -0700 (PDT) Received: from ppp118-209-0-107.lns20.mel4.internode.on.net ([118.209.0.107]:51326 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XjFdr-0004KV-5y for rtcweb@ietf.org; Wed, 29 Oct 2014 09:53:31 +1100 Message-ID: <54501EA8.9010308@nteczone.com> Date: Wed, 29 Oct 2014 09:54:32 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> <544FF8CE.5070304@alum.mit.edu> <5450153B.8000808@alum.mit.edu> In-Reply-To: <5450153B.8000808@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ELUFmipVjqcq4aokhPuBCkV_O2o Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 22:54:46 -0000 +1 for removing webrtc from data channel and making it clearer that it can be used as a general mechanism. That's why I thought there should be a separate ALPN in draft-ietf-rtcweb-alpn-00 for data channel only usage rather than saying SRTP may be absent. Regards, Christian On 29/10/2014 9:14 AM, Paul Kyzivat wrote: > Mary pointed out an important typo in this message. Correction inline. > > On 10/28/14 4:13 PM, Paul Kyzivat wrote: >> (This thread has gotten long, and its hard to figure where to jump in. >> I'm just replying to the last message I see, but am commenting on the >> thread in total.) >> >> Regarding data channels being webrtc-specific: >> >> I don't see it that way. Webrtc has opened up restricted communication >> among browsers. If you want to talk to a browser, you have few choices, >> and this is the one that is "general purpose". So any application that >> sometimes might need to run in a browser is a likely candidate for data >> channels. And then, when non-browser versions of that app are talking to >> one another, it will be most practical to use the same mechanism. >> >> That is why CLUE is using data channels - even if we think that *most* >> of the endpoints won't be in browsers. >> >> Regarding NDATA: >> >> ISTM that SCTP just screwed up in not including the NDATA features in >> the base protocol. Going forward, it always should be included in new >> implementations. Since data channels are being defined after NDATA, it >> is perfectly reasonable for data channels to require NDATA support. >> >> IIUC, while NDATA allows fragmentation to avoid head of line blocking, >> that doesn't mean the messages will be fragmented unnecessarily. If you >> are only using one channel I *think* it likely that even a large message >> won't be fragmented. So it will be harmless insurance. >> >> Christer said that since CLUE only needs one data channel there is no >> need for NDATA. Someone specifying BFCP over data channel might reach a >> similar conclusion for it. But there is nothing to prevent an >> application that implements both CLUE and BFCP. Independently they >> wouldn't need NDATA, but together they would. >> >> So I am in favor of making NDATA mandatory to implement, offer, and >> accept for data channels. >> >> But I would still like the data channel spec to acknowledge that, while >> webrtc is a *very* important client, that the protocol solely for >> webrtc. And with that in mind I would like to see "webrtc" removed from >> the name of the protocol. (E.g., in the SDP m-line.) > > What I meant to say in the last paragraph is: > > But I would still like the data channel spec to acknowledge that, > while webrtc is a *very* important client, that the protocol *is not* > solely for webrtc. And with that in mind I would like to see "webrtc" > removed from the name of the protocol. (E.g., in the SDP m-line.) > > Thanks, > Paul > > >> On 10/28/14 1:53 PM, Christer Holmberg wrote: >>> Hi, >>> >>> >>> I am not suggesting different flavors - I am suggesting to >>> make >>> the usage of >>> >>> interleaving optional. Other SCTP features are also optional >>> (including reliability, ordering etc). >>> >>> >>> >>> Where are these things optional? According to >>> >>> >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section >>> >>> -6.1 an implementation MUST implement PR-SCTP and the support >>> of the >>> >>> FORWARD-TSN chunk will be negotiated similar to the NDATA >>> chunk. I don't see a difference, especially not if we move to MUST >>> support NDATA. >>> >> >>> >> For example, section 6.1 says: >>> >> >>> >> "The partial reliability extension defined in [RFC3758] >>> MUST be supported." >>> >> >>> >> However, in CLUE we say that a CLUE entity MUST NOT *use* the >>> extension, as all CLUE messages are required to be sent reliably. >>> > >>> > That is OK. However, support for PR-SCTP MUST be there and it >>> will be negotiated. You just never send a message with partial >>> reliability. At least this is my understanding... >>> >>> So, can the same be done for interleaving? I.e. the support MUST be >>> there, but e.g. CLUE entities can choose not to use it? >>> >>> Note that my issue is not about support, it's about usage :) >>> >>> What resource is being conserved by not just requiring it? >>> >>> I don’t know. The task is to figure out whether there are *technical* >>> reasons to mandate usage of certain SCTP features for CLUE. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> _______________________________________________ >>> 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 nobody Tue Oct 28 17:01:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1FB1A1B89 for ; Tue, 28 Oct 2014 17:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-R76iCbevDZ for ; Tue, 28 Oct 2014 17:01:40 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BDA1A1B7E for ; Tue, 28 Oct 2014 17:01:39 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 82CCD2B12ED; Wed, 29 Oct 2014 00:01:34 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9T01btA025723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 20:01:38 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 20:01:37 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Christian Groves , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: AQHP8e/nIllG4P1iiEigF/2tAwwrVZxGFVASgABOJAD//85CEA== Date: Wed, 29 Oct 2014 00:01:37 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> <544FF8CE.5070304@alum.mit.edu> <5450153B.8000808@alum.mit.edu> <54501EA8.9010308@nteczone.com> In-Reply-To: <54501EA8.9010308@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EHVCu1nNiORUih23YEK_31w80vM Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 00:01:44 -0000 +1 for making data channel as webrtc independent. +1 for making NDATA a MUST for webrtc use of data channels only. As we have seen in recent posts NDATA is not risk free and has "baggage"= associated to it. My detailed view is explained in the post: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13322.html BR Raju > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christian Grov= es > Sent: Tuesday, October 28, 2014 5:55 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving >=20 > +1 for removing webrtc from data channel and making it clearer that it > can be used as a general mechanism. That's why I thought there should be > a separate ALPN in draft-ietf-rtcweb-alpn-00 for data channel only usage > rather than saying SRTP may be absent. >=20 > Regards, Christian >=20 > On 29/10/2014 9:14 AM, Paul Kyzivat wrote: > > Mary pointed out an important typo in this message. Correction inline. > > > > On 10/28/14 4:13 PM, Paul Kyzivat wrote: > >> (This thread has gotten long, and its hard to figure where to jump in. > >> I'm just replying to the last message I see, but am commenting on the > >> thread in total.) > >> > >> Regarding data channels being webrtc-specific: > >> > >> I don't see it that way. Webrtc has opened up restricted communication > >> among browsers. If you want to talk to a browser, you have few choices= , > >> and this is the one that is "general purpose". So any application that > >> sometimes might need to run in a browser is a likely candidate for dat= a > >> channels. And then, when non-browser versions of that app are talking = to > >> one another, it will be most practical to use the same mechanism. > >> > >> That is why CLUE is using data channels - even if we think that *most* > >> of the endpoints won't be in browsers. > >> > >> Regarding NDATA: > >> > >> ISTM that SCTP just screwed up in not including the NDATA features in > >> the base protocol. Going forward, it always should be included in new > >> implementations. Since data channels are being defined after NDATA, it > >> is perfectly reasonable for data channels to require NDATA support. > >> > >> IIUC, while NDATA allows fragmentation to avoid head of line blocking, > >> that doesn't mean the messages will be fragmented unnecessarily. If yo= u > >> are only using one channel I *think* it likely that even a large messa= ge > >> won't be fragmented. So it will be harmless insurance. > >> > >> Christer said that since CLUE only needs one data channel there is no > >> need for NDATA. Someone specifying BFCP over data channel might reach = a > >> similar conclusion for it. But there is nothing to prevent an > >> application that implements both CLUE and BFCP. Independently they > >> wouldn't need NDATA, but together they would. > >> > >> So I am in favor of making NDATA mandatory to implement, offer, and > >> accept for data channels. > >> > >> But I would still like the data channel spec to acknowledge that, whil= e > >> webrtc is a *very* important client, that the protocol solely for > >> webrtc. And with that in mind I would like to see "webrtc" removed fro= m > >> the name of the protocol. (E.g., in the SDP m-line.) > > > > What I meant to say in the last paragraph is: > > > > But I would still like the data channel spec to acknowledge that, > > while webrtc is a *very* important client, that the protocol *is not* > > solely for webrtc. And with that in mind I would like to see "webrtc" > > removed from the name of the protocol. (E.g., in the SDP m-line.) > > > > Thanks, > > Paul > > > > > >> On 10/28/14 1:53 PM, Christer Holmberg wrote: > >>> Hi, > >>> > >>> >>> I am not suggesting different flavors - I am suggesting to > >>> make > >>> the usage of > >>> >>> interleaving optional. Other SCTP features are also optional > >>> (including reliability, ordering etc). > >>> >>> > >>> >>> Where are these things optional? According to > >>> >>> > >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section > >>> >>> -6.1 an implementation MUST implement PR-SCTP and the suppor= t > >>> of the > >>> >>> FORWARD-TSN chunk will be negotiated similar to the NDATA > >>> chunk. I don't see a difference, especially not if we move to MUS= T > >>> support NDATA. > >>> >> > >>> >> For example, section 6.1 says: > >>> >> > >>> >> "The partial reliability extension defined in [RFC3758] > >>> MUST be supported." > >>> >> > >>> >> However, in CLUE we say that a CLUE entity MUST NOT *use* the > >>> extension, as all CLUE messages are required to be sent reliably. > >>> > > >>> > That is OK. However, support for PR-SCTP MUST be there and it > >>> will be negotiated. You just never send a message with partial > >>> reliability. At least this is my understanding... > >>> > >>> So, can the same be done for interleaving? I.e. the support MUST = be > >>> there, but e.g. CLUE entities can choose not to use it? > >>> > >>> Note that my issue is not about support, it's about usage :) > >>> > >>> What resource is being conserved by not just requiring it? > >>> > >>> I don't know. The task is to figure out whether there are *technical* > >>> reasons to mandate usage of certain SCTP features for CLUE. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Oct 28 18:27:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82871A1BDC for ; Tue, 28 Oct 2014 18:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgvNK14tHEr8 for ; Tue, 28 Oct 2014 18:27:49 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0651A1BDD for ; Tue, 28 Oct 2014 18:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7489; q=dns/txt; s=iport; t=1414546068; x=1415755668; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3Y4kS6iTeEc0CkNp2QZAQgVVZ8izP2xNOkbxptVTsmo=; b=DwG2DCNFbtv+5JfX9U0l18jk80uTX5uDvi8ZPkI24evMqJd4KgGIZ5fH y9Cyi0KOQXgMfNka298FJk5l+a/rNdHN/KCaVK6F3QkN/pWLxvz1Thnt3 EboOhmCyMMn+ir/c5M3iQU5yYS8kFLzeysl7aKD4hLHF6o3iTSnw1tlQF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFABBBUFStJA2F/2dsb2JhbABcgkhGVFgEzkWHTQKBHhYBAQEBAX2EAwEBBG4LEAIBCD8HMhQRAgQOBQmIOA3FIAEBAQEBBQEBAQEBAQEBGpA4AQFPB4RLBZILi12BMYNJkTyBfiCBWmwBgQ45gQMBAQE X-IronPort-AV: E=Sophos; i="5.04,806,1406592000"; d="scan'208,217"; a="91223232" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP; 29 Oct 2014 01:27:47 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9T1RkCI016989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 01:27:46 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.159]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 20:27:46 -0500 From: "Mo Zanaty (mzanaty)" To: Michael Tuexen Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving Thread-Index: AQHP8xeLiqONAZMCbkeGY9lGqqITSg== Date: Wed, 29 Oct 2014 01:27:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> In-Reply-To: <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.82.211.189] Content-Type: multipart/alternative; boundary="_000_D075BA5D3D254mzanatyciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QqJApRSzxD2ZRJAwocWtx001qAs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 01:27:52 -0000 --_000_D075BA5D3D254mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Moved to tsvwg: http://www.ietf.org/mail-archive/web/tsvwg/current/msg12892.html On 10/28/14, 6:28 PM, Mo Zanaty (mzanaty) > wrote: On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" > wrote: On 28 Oct 2014, at 21:52, Mo Zanaty (mzanaty) > wrote: What resource is being conserved by not just requiring it? 8 bytes per packet (for MID+FSN). Michael, the current NDATA draft requires it to be used for all messages if= negotiated. Can=92t this be relaxed / optimized to use it for all *fragmen= ted* messages but use DATA for non-fragmented messages to avoid the 8 byte = overhead for small messages (like game telemetry/control, an often cited us= e of data channels). You can bring this up at the tsvwg mailing list. Mo: Will do. However, we normally do not optimize for byte saving... Mixing both makes the processing harder... Maybe we can use a bit in the flags to = indicate if the additional fields are there... Mo: Type should already be enough without flags. The current NDATA draft also says you can=92t interleave fragmented message= s in a stream, so head of line blocking remains for all fragmented messages= , while only small non-fragmented messages can avoid it. This dilutes the u= tility of NDATA, perhaps enough to make apps that really care about head of= line blocking to implement their own app layer fragmentation with messages= well below common MTUs, hence defeating NDATA. Can=92t this also be relaxe= d since MID is part of the NDATA extra header? This would only make sense for messages marked as unordered... For ordered = it doesn't make sense. Mo: The restriction applies to unordered as well as ordered. Even for order= ed, it does make sense to avoid head of line blocking at the sender. If those two issues are resolved, I see no argument against making NDATA a = MUST in data channels. Please let us discuss NDATA issues on the tsvwg mailing list... Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its benefits= outweigh its costs. The current draft does not pass that bar for me. If my= app cares about HOL blocking, NDATA is not very useful, so my app must int= ernally fragment, hence NDATA actually becomes harmful (8 bytes closer to e= xceeding MTU, forcing SCTP fragments and hence risking HOL blocking). Best regards Michael Mo PS. Some believe data channels will be more widely used than WebRTC media (= webtorrent, etc.), so it does make sense to consider the desirable properti= es of a general peer-to-peer transport, and drop the WebRTC prefix when tal= king about data channels. --_000_D075BA5D3D254mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <236BF56CCF30FB4E8CC62AF6122E07EE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Moved to tsvwg:

On 10/28/14, 6:28 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de<= /a>> wrote:
What resource is being conserved by not just requiring it?
8 bytes per packet (for MID+FSN).
Michael, the current NDATA draft requires it to be used for all messag= es if negotiated. Can=92t this be relaxed / optimized to use it for all *fr= agmented* messages but use DATA for non-fragmented messages to avoid the 8 = byte overhead for small messages (like game telemetry/control, an often cited use of data channels).
You can bring this up at the tsvwg mailing list.
Mo: Will do.
However, we normally do not optimize for byte saving... Mixing
both makes the processing harder... Maybe we can use a bit in the flag= s to indicate if the additional fields are
there...
Mo: Type should already be enough without flags.
The current NDATA draft also says you can=92t interleave fragmented me= ssages in a stream, so head of line blocking remains for all fragmented mes= sages, while only small non-fragmented messages can avoid it. This dilutes = the utility of NDATA, perhaps enough to make apps that really care about head of line blocking to implement the= ir own app layer fragmentation with messages well below common MTUs, hence = defeating NDATA. Can=92t this also be relaxed since MID is part of the NDAT= A extra header?
This would only make sense for messages marked as unordered... For ord= ered it doesn't make sense.
Mo: The restriction applies to unordered as well as ordered. Even for = ordered, it does make sense to avoid head of line blocking at the sender.
If those two issues are resolved, I see no argument against making NDA= TA a MUST in data channels.
Please let us discuss NDATA issues on the tsvwg mailing list...
Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its ben= efits outweigh its costs. The current draft does not pass that bar for me. = If my app cares about HOL blocking, NDATA is not very useful, so my app mus= t internally fragment, hence NDATA actually becomes harmful (8 bytes closer to exceeding MTU, forcing SCTP fr= agments and hence risking HOL blocking).
Best regards
Michael
Mo
PS. Some believe data channels will be more widely used than WebRTC me= dia (webtorrent, etc.), so it does make sense to consider the desirable pro= perties of a general peer-to-peer transport, and drop the WebRTC prefix whe= n talking about data channels.

--_000_D075BA5D3D254mzanatyciscocom_-- From nobody Tue Oct 28 21:23:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543E21A6F5A for ; Tue, 28 Oct 2014 21:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.012 X-Spam-Level: * X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x92ZPh7YB09q for ; Tue, 28 Oct 2014 21:23:55 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD331A0111 for ; Tue, 28 Oct 2014 21:23:55 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wp18so1767273obc.2 for ; Tue, 28 Oct 2014 21:23:54 -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; bh=yxyU+VmvZjPo9bm+luWx1EmcdsCq+aihN86SdwYv4q0=; b=kc+GgMMCNXYAeNGhbReWNxU96Tszq7ryhL482hH+ivpmimM/2CErXvqOPhRGOOFDSG J69Gmvcy30o1QdJdDPMb4ABhcVZA1oZFfx95p1MmOFptTk5ySJRmMAowneUeb1RB6pWv CmNR0Ynu9AFfmUguAcTxV6RGb3z8QhtRkvcNULl7NKRqYANZkL348w0QA4ijT1kG7z6b XOtReC9vsFCiTh12jFK3TUaPVte97J1gWCruftdyivaqKVA7jESE6bWiN0RgM6qYFHrH dkdPx14XT24pQ5h7ekAI2Ysm0lRvY1sjkuvBt6TU82h90WlhTXakJdRQTavwz/GJCf/Y iVng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yxyU+VmvZjPo9bm+luWx1EmcdsCq+aihN86SdwYv4q0=; b=a6Z92uez4yGEo/ynSDKAm0+p97P1bKrN8JzJjZ5ZBXNuhU7O8YZoZHP+RVkTlKPDti 0CdyldT910bc1bMPKQgYudGPx+C8ob7v3vO7tPNZZ64jNQ3kVqHVyrNFNDGd5aJSu6WE CZTcJbuHyUiddc0uliADUtum+Po8WRZQ1Ujzwc+c/q3DgbWzpsEUxIQOK89AOFT5kl9I 0tHSppsJANatdiL5tm2Gwi9DsGVMQyI8DkFLVJn4pt/KzhcKpuR8tw4hv5Y+DsqiQgT4 XIvvWF04Q+yihN9QYyWyU8YOSl4DDxyoeUC6KO6pfYFdS0+BzaQZQpcHSAGXuJqUjcZ5 aQlQ== X-Gm-Message-State: ALoCoQmvey3ubwwn4tfA9KccLXDRxhOoLg2qAhwunEdqcMPFBsINDF715VdUBe8FJQmMKi/GT2KF X-Received: by 10.182.130.232 with SMTP id oh8mr79603obb.49.1414556634701; Tue, 28 Oct 2014 21:23:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Tue, 28 Oct 2014 21:23:34 -0700 (PDT) In-Reply-To: References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> <544936E5.2040909@mozilla.com> From: Justin Uberti Date: Tue, 28 Oct 2014 21:23:34 -0700 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=089e013a03c6ba0660050688216d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kyu8mQZMgNA2JIADCJaiDlaw2IM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 04:23:57 -0000 --089e013a03c6ba0660050688216d Content-Type: text/plain; charset=UTF-8 So it's not clear to me that a=ssrc:X fmtp:Y is actually legal, without any fmtp parameters, or that it clearly indicates that only PT Y is to be sent on that SSRC. As such, I consider this solution to be wishful thinking. I think it would be easier if we defined FEC/FID semantics such that the initial SSRC was to be used for the primary encoding, and any subsequent SSRCs were used for the secondary/tertiary streams. (e.g. RTX or FEC) e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC: m=video 30000 RTP/AVP 100 101 108 109 110 111 c=IN IP4 233.252.0.1 a=rtpmap:100 VP8/90000 a=rtpmap:101 VP9/90000 a=rtpmap:108 rtx/90000 a=rtpmap:109 rtx/90000 a=fmtp:108 apt=100 a=fmtp:109 apt=101 a=rtpmap:110 interleaved-parityfec/90000 a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000 a=rtpmap:111 non-interleaved-parityfec/90000 a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000 a=ssrc:1234 a=ssrc:2345 a=ssrc:3456 a=ssrc:4567 a=ssrc-group:FID 1234 2345 a=ssrc-group:FEC-FR 1234 3456 4567 SSRC 1234 is the primary encoding (VP8 or VP9) SSRC 2345 is RTX (either PT 108 or 109, as needed) SSRC 3456 is FEC (either PT 110 or 111, depending on impl) SSRC 4567 is FEC (either PT 110 or 111, depending on impl) On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > > > > Makaraju, Maridi Raju (Raju) wrote: > > > OPUS does have a built-in FEC so no need for red+ulpfec. > > > > As discussed previously on this list [1] the built-in FEC only covers > > the SILK layer. Existing codec-agnostic mechanisms were perfectly > > adequate for protecting CELT-mode packets, so we didn't invent something > > new. > > > > [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html > [Raju] Thanks and appreciate the reference. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e013a03c6ba0660050688216d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So it's not clear to me that a=3Dssrc:X fmtp:Y is actu= ally legal, without any fmtp parameters, or that it clearly indicates that = only PT Y is to be sent on that SSRC. As such, I consider this solution to = be wishful thinking.

I think it would be easier if we de= fined FEC/FID semantics such that the initial SSRC was to be used for the p= rimary encoding, and any subsequent SSRCs were used for the secondary/terti= ary streams. (e.g. RTX or FEC)

e.g. for a stream w= ith 2 video codecs, RTX and 1d/2d FEC:
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0m=3Dvideo 30000 RTP/AVP 100 101 108 109 110 111
=C2=A0 =C2=A0 =C2=A0c=3DIN IP4 233.252.0.1
=C2=A0 = =C2=A0 =C2=A0a=3Drtpmap:100 VP8/90000
=C2=A0 =C2=A0 =C2=A0a=3Drtp= map:101 VP9/90000
=C2=A0 =C2=A0 =C2=A0a=3Drtpmap:108 rtx/9000= 0
=C2=A0 =C2=A0 =C2=A0a=3Drtpmap:109 rtx/90000
=C2= =A0 =C2=A0 =C2=A0a=3Dfmtp:108 apt=3D100
=C2=A0 =C2=A0 =C2=A0a=3Df= mtp:109 apt=3D101
=C2=A0 =C2=A0 =C2=A0a=3Drtpmap:110 interlea= ved-parityfec/90000
=C2=A0 =C2=A0 =C2=A0a=3Dfmtp:110 L:5; D:10; T= oP:2; repair-window:200000
=C2=A0 =C2=A0 =C2=A0a=3Drtpmap:111 non= -interleaved-parityfec/90000
=C2=A0 =C2=A0 =C2=A0a=3Dfmtp:111 L:5= ; D:10; ToP:2; repair-window:200000
=C2=A0 =C2=A0 =C2=A0a=3Dssrc:= 1234
=C2=A0 =C2=A0 =C2=A0a=3Dssrc:2345
=C2=A0 =C2=A0 = =C2=A0a=3Dssrc:3456
=C2=A0 =C2=A0 =C2=A0a=3Dssrc:4567
= =C2=A0 =C2=A0 =C2=A0a=3Dssrc-group:FID 1234 2345
=C2=A0 =C2=A0 = =C2=A0a=3Dssrc-group:FEC-FR 1234 3456 4567

S= SRC 1234 is the primary encoding (VP8 or VP9)
SSRC 2345 is RTX (e= ither PT 108 or 109, as needed)
SSRC 3456 is FEC (either PT 110 o= r 111, depending on impl)
SSRC 4567 is FEC (either PT 110 or 111,= depending on impl)

On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Ma= ridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com><= /span> wrote:
>
> Makaraju, Maridi Raju (Raju) wrote:
> > OPUS does have a built-in FEC so no need for red+ulpfec.
>
> As discussed previously on this list [1] the built-in FEC only covers<= br> > the SILK layer. Existing codec-agnostic mechanisms were perfectly
> adequate for protecting CELT-mode packets, so we didn't invent som= ething
> new.
>
> [1] https://www.ietf.org/mail-archive/web/rtcweb= /current/msg12353.html
[Raju] Thanks and appreciate the reference.

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

--089e013a03c6ba0660050688216d-- From nobody Tue Oct 28 22:22:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B451A6FDD for ; Tue, 28 Oct 2014 22:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsvE7B0ldmv1 for ; Tue, 28 Oct 2014 22:22:31 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45291A6FD6 for ; Tue, 28 Oct 2014 22:22:30 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gq15so1853122lab.21 for ; Tue, 28 Oct 2014 22:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zPYz6A187fE9I7reyvJ08oSNe6GjvAs1TKQM9aQYrbs=; b=tez+djhKqeQ2AR1KBymcmmwEHQNHNkhEbFdQc2EyJB3bSfYCqbgN/vdL3i+vLjkeiz ddnorF+WWqHsE0cwr7es/6ldOeMnc0FDfZXm9NToKPW9HNYGuSr947Pj54XQecm+6N7S iYDZWtdHMAWZU5bsB4RWrL4/vdlO/sR34u+XBhWDIqiCiy+qdEr/Ac4SvX6pu2DTb1fe LdAwE9pxNLNVpddFNzOm6OPkAo+NmWL7vrY1v9+dhxceTDN1unF72QHdLXo6+tKvXIvg 5s2qQyuYqu658VitYCOF4jT/ZIQh/s7yCd439/SnAxH5RehaYijw+k4ES8qzACv3Iuht ZlKA== MIME-Version: 1.0 X-Received: by 10.112.63.70 with SMTP id e6mr546904lbs.93.1414560149048; Tue, 28 Oct 2014 22:22:29 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Tue, 28 Oct 2014 22:22:28 -0700 (PDT) Received: by 10.25.215.217 with HTTP; Tue, 28 Oct 2014 22:22:28 -0700 (PDT) In-Reply-To: References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> <544936E5.2040909@mozilla.com> Date: Tue, 28 Oct 2014 22:22:28 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c3ee74329387050688f315 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2f8JdA512qv8hMMk6BMsNeqgLJI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 05:22:33 -0000 --001a11c3ee74329387050688f315 Content-Type: text/plain; charset=UTF-8 Sounds like a reasonable idea to me, but don't you have to specify a strict pecking order? RTX before FEC doesn't sound right to me, but that's pure prejudice/bias (FEC is always present, and optional stuff his last) So how would you decide that order? A hat? PT value? Order of PT on the m line? Order of the fmtp attributes? Something else? Or can we simply fix the order, since there are only a small number of variations to consider? On Oct 28, 2014 9:24 PM, "Justin Uberti" wrote: > So it's not clear to me that a=ssrc:X fmtp:Y is actually legal, without > any fmtp parameters, or that it clearly indicates that only PT Y is to be > sent on that SSRC. As such, I consider this solution to be wishful thinking. > > I think it would be easier if we defined FEC/FID semantics such that the > initial SSRC was to be used for the primary encoding, and any subsequent > SSRCs were used for the secondary/tertiary streams. (e.g. RTX or FEC) > > e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC: > > m=video 30000 RTP/AVP 100 101 108 109 110 111 > c=IN IP4 233.252.0.1 > a=rtpmap:100 VP8/90000 > a=rtpmap:101 VP9/90000 > a=rtpmap:108 rtx/90000 > a=rtpmap:109 rtx/90000 > a=fmtp:108 apt=100 > a=fmtp:109 apt=101 > a=rtpmap:110 interleaved-parityfec/90000 > a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000 > a=rtpmap:111 non-interleaved-parityfec/90000 > a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000 > a=ssrc:1234 > a=ssrc:2345 > a=ssrc:3456 > a=ssrc:4567 > a=ssrc-group:FID 1234 2345 > a=ssrc-group:FEC-FR 1234 3456 4567 > > SSRC 1234 is the primary encoding (VP8 or VP9) > SSRC 2345 is RTX (either PT 108 or 109, as needed) > SSRC 3456 is FEC (either PT 110 or 111, depending on impl) > SSRC 4567 is FEC (either PT 110 or 111, depending on impl) > > > On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) < > Raju.Makaraju@alcatel-lucent.com> wrote: > >> > >> > Makaraju, Maridi Raju (Raju) wrote: >> > > OPUS does have a built-in FEC so no need for red+ulpfec. >> > >> > As discussed previously on this list [1] the built-in FEC only covers >> > the SILK layer. Existing codec-agnostic mechanisms were perfectly >> > adequate for protecting CELT-mode packets, so we didn't invent something >> > new. >> > >> > [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html >> [Raju] Thanks and appreciate the reference. >> >> _______________________________________________ >> 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 > > --001a11c3ee74329387050688f315 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sounds like a reasonable idea to me, but don't you have = to specify a strict pecking order? RTX before FEC doesn't sound right t= o me, but that's pure prejudice/bias (FEC is always present, and option= al stuff his last)

So how would you decide that order? A hat? PT value? Order o= f PT on the m line? Order of the fmtp attributes? Something else? Or can we= simply fix the order, since there are only a small number of variations to= consider?

On Oct 28, 2014 9:24 PM, "Justin Uberti&quo= t; <juberti@google.com> wro= te:
So it's not clear to me that a=3Dssrc:X fmtp:Y is actually legal, with= out any fmtp parameters, or that it clearly indicates that only PT Y is to = be sent on that SSRC. As such, I consider this solution to be wishful think= ing.

I think it would be easier if we defined FEC/FID se= mantics such that the initial SSRC was to be used for the primary encoding,= and any subsequent SSRCs were used for the secondary/tertiary streams. (e.= g. RTX or FEC)

e.g. for a stream with 2 video code= cs, RTX and 1d/2d FEC:
=C2=A0=C2=A0
=C2=A0 =C2= =A0 =C2=A0m=3Dvideo 30000 RTP/AVP 100 101 108 109 110 111
=C2= =A0 =C2=A0 =C2=A0c=3DIN IP4 233.252.0.1
=C2=A0 =C2=A0 =C2=A0a=3Dr= tpmap:100 VP8/90000
=C2=A0 =C2=A0 =C2=A0a=3Drtpmap:101 VP9/90000<= br>
=C2=A0 =C2=A0 =C2=A0a=3Drtpmap:108 rtx/90000
=C2=A0= =C2=A0 =C2=A0a=3Drtpmap:109 rtx/90000
=C2=A0 =C2=A0 =C2=A0a= =3Dfmtp:108 apt=3D100
=C2=A0 =C2=A0 =C2=A0a=3Dfmtp:109 apt=3D101<= br>
=C2=A0 =C2=A0 =C2=A0a=3Drtpmap:110 interleaved-parityfec/9000= 0
=C2=A0 =C2=A0 =C2=A0a=3Dfmtp:110 L:5; D:10; ToP:2; repair-windo= w:200000
=C2=A0 =C2=A0 =C2=A0a=3Drtpmap:111 non-interleaved-parit= yfec/90000
=C2=A0 =C2=A0 =C2=A0a=3Dfmtp:111 L:5; D:10; ToP:2; rep= air-window:200000
=C2=A0 =C2=A0 =C2=A0a=3Dssrc:1234
=C2= =A0 =C2=A0 =C2=A0a=3Dssrc:2345
=C2=A0 =C2=A0 =C2=A0a=3Dssrc:3456<= /div>
=C2=A0 =C2=A0 =C2=A0a=3Dssrc:4567
=C2=A0 =C2=A0 =C2=A0a= =3Dssrc-group:FID 1234 2345
=C2=A0 =C2=A0 =C2=A0a=3Dssrc-group:FE= C-FR 1234 3456 4567

SSRC 1234 is the primary= encoding (VP8 or VP9)
SSRC 2345 is RTX (either PT 108 or 109, as= needed)
SSRC 3456 is FEC (either PT 110 or 111, depending on imp= l)
SSRC 4567 is FEC (either PT 110 or 111, depending on impl)


On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
>
> Makaraju, Maridi Raju (Raju) wrote:
> > OPUS does have a built-in FEC so no need for red+ulpfec.
>
> As discussed previously on this list [1] the built-in FEC only covers<= br> > the SILK layer. Existing codec-agnostic mechanisms were perfectly
> adequate for protecting CELT-mode packets, so we didn't invent som= ething
> new.
>
> [1] https://www.ietf.org/mail-archive/web/rtcweb= /current/msg12353.html
[Raju] Thanks and appreciate the reference.

_______________________________________________
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

--001a11c3ee74329387050688f315-- From nobody Tue Oct 28 22:51:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6102E1A014C for ; Tue, 28 Oct 2014 22:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.51 X-Spam-Level: X-Spam-Status: No, score=-11.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBd9Zrk0HRUJ for ; Tue, 28 Oct 2014 22:51:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32AA1A016D for ; Tue, 28 Oct 2014 22:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10143; q=dns/txt; s=iport; t=1414561869; x=1415771469; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tjVWzlsmm8oeFyjuI1kVqTiKYAri7l4IGFSVkVGBmyE=; b=htYjPku3jx4GBIiTaTEhrbE5IAszgolHoLYjCtOT+jSU+PQkK13kdQPT Yz3xORB0g/f+CD+M4aRQQicb3R8mGOLJDzLrQbUkpHUUj8igIaPQY7wll y85qgCh4NYU+UOHQglYvWOXLz+a+UpfpovSQ3RGWDS9D8jbmn75yk0CoI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFANd/UFStJV2b/2dsb2JhbABcgkhGVFgEzkUBCYZ5VAKBFxYBAQEBAX2EAgEBAQMBAQEBZAcLEAIBCBgnByEGCxQRAgQBDQUbiBEDCQkNvkMNhjgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI5PgWkBAUsEB4RLBYUVAox0hw2CP4IRj1WGY4N4bAGBDjmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,808,1406592000"; d="scan'208,217";a="367383340" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 29 Oct 2014 05:51:05 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9T5p5Aj024535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 05:51:05 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.159]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 00:51:05 -0500 From: "Mo Zanaty (mzanaty)" To: Martin Thomson , Justin Uberti Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP8zxUqi1i1wqR+EyDmy+Vgek/aA== Date: Wed, 29 Oct 2014 05:51:05 +0000 Message-ID: References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> <544936E5.2040909@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.82.211.189] Content-Type: multipart/alternative; boundary="_000_D075F3CB3D2D6mzanatyciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d1aTtg3HogfKU-jrBoLfYw_qDgM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 05:51:11 -0000 --_000_D075F3CB3D2D6mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think Justin meant the =93initial SSRC=94 in the a=3Dssrc-group lines car= ries significance (as the source), not the order of a=3Dssrc lines. What if new FEC schemes defined for bundle / unified plan (such as those be= low) followed the example of RTX by including apt=3D100 in their fmtp param= eters? So PT can be used to associate source and FEC flows without declarin= g any SSRCs or groups. We can also improve on RTX by allowing apt=3D100,101 for FEC. When we consider more complex cases like RTX/FEC with simulcast and scalabl= e streams in unified plan, using PT association may be better than declarin= g many SSRCs (which is also problematic in cases of collisions, dynamic sou= rces, switching mixers, etc.). Mo On 10/29/14, 1:22 AM, Martin Thomson > wrote: Sounds like a reasonable idea to me, but don't you have to specify a strict= pecking order? RTX before FEC doesn't sound right to me, but that's pure p= rejudice/bias (FEC is always present, and optional stuff his last) So how would you decide that order? A hat? PT value? Order of PT on the m l= ine? Order of the fmtp attributes? Something else? Or can we simply fix the= order, since there are only a small number of variations to consider? On Oct 28, 2014 9:24 PM, "Justin Uberti" > wrote: So it's not clear to me that a=3Dssrc:X fmtp:Y is actually legal, without a= ny fmtp parameters, or that it clearly indicates that only PT Y is to be se= nt on that SSRC. As such, I consider this solution to be wishful thinking. I think it would be easier if we defined FEC/FID semantics such that the in= itial SSRC was to be used for the primary encoding, and any subsequent SSRC= s were used for the secondary/tertiary streams. (e.g. RTX or FEC) e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC: m=3Dvideo 30000 RTP/AVP 100 101 108 109 110 111 c=3DIN IP4 233.252.0.1 a=3Drtpmap:100 VP8/90000 a=3Drtpmap:101 VP9/90000 a=3Drtpmap:108 rtx/90000 a=3Drtpmap:109 rtx/90000 a=3Dfmtp:108 apt=3D100 a=3Dfmtp:109 apt=3D101 a=3Drtpmap:110 interleaved-parityfec/90000 a=3Dfmtp:110 L:5; D:10; ToP:2; repair-window:200000 a=3Drtpmap:111 non-interleaved-parityfec/90000 a=3Dfmtp:111 L:5; D:10; ToP:2; repair-window:200000 a=3Dssrc:1234 a=3Dssrc:2345 a=3Dssrc:3456 a=3Dssrc:4567 a=3Dssrc-group:FID 1234 2345 a=3Dssrc-group:FEC-FR 1234 3456 4567 SSRC 1234 is the primary encoding (VP8 or VP9) SSRC 2345 is RTX (either PT 108 or 109, as needed) SSRC 3456 is FEC (either PT 110 or 111, depending on impl) SSRC 4567 is FEC (either PT 110 or 111, depending on impl) On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) > wrote: > > Makaraju, Maridi Raju (Raju) wrote: > > OPUS does have a built-in FEC so no need for red+ulpfec. > > As discussed previously on this list [1] the built-in FEC only covers > the SILK layer. Existing codec-agnostic mechanisms were perfectly > adequate for protecting CELT-mode packets, so we didn't invent something > new. > > [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html [Raju] Thanks and appreciate the reference. _______________________________________________ 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_D075F3CB3D2D6mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <32A74E8E34251149B593802A844AB565@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I think Justin meant the =93initial SSRC=94 in the a=3Dssrc-group line= s carries significance (as the source), not the order of a=3Dssrc lines.

What if new FEC schemes defined for bundle / unified plan (such as tho= se below) followed the example of RTX by including apt=3D100 in their fmtp = parameters? So PT can be used to associate source and FEC flows without dec= laring any SSRCs or groups.

We can also improve on RTX by allowing apt=3D100,101 for FEC.

When we consider more complex cases like RTX/FEC with simulcast and sc= alable streams in unified plan, using PT association may be better than dec= laring many SSRCs (which is also problematic in cases of collisions, dynami= c sources, switching mixers, etc.).

Mo


On 10/29/14, 1:22 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
Sounds like a reasonable idea to me, but don't you have to specify a s= trict pecking order? RTX before FEC doesn't sound right to me, but that's p= ure prejudice/bias (FEC is always present, and optional stuff his last)

So how would you decide that order? A hat? PT value? Order o= f PT on the m line? Order of the fmtp attributes? Something else? Or can we= simply fix the order, since there are only a small number of variations to= consider?

On Oct 28, 2014 9:24 PM, "Justin Uberti&quo= t; <juberti@google.com> wro= te:
So it's not clear to me that a=3Dssrc:X fmtp:Y is actually= legal, without any fmtp parameters, or that it clearly indicates that only= PT Y is to be sent on that SSRC. As such, I consider this solution to be w= ishful thinking.

I think it would be easier if we defined FEC/FID semantics such that t= he initial SSRC was to be used for the primary encoding, and any subsequent= SSRCs were used for the secondary/tertiary streams. (e.g. RTX or FEC)

e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC:
  
     m=3Dvideo 30000 RTP/AVP 100 101 108 109 110 111
     c=3DIN IP4 233.252.0.1
     a=3Drtpmap:100 VP8/90000
     a=3Drtpmap:101 VP9/90000
     a=3Drtpmap:108 rtx/90000
     a=3Drtpmap:109 rtx/90000
     a=3Dfmtp:108 apt=3D100
     a=3Dfmtp:109 apt=3D101
     a=3Drtpmap:110 interleaved-parityfec/90000
     a=3Dfmtp:110 L:5; D:10; ToP:2; repair-window:20000= 0
     a=3Drtpmap:111 non-interleaved-parityfec/90000
     a=3Dfmtp:111 L:5; D:10; ToP:2; repair-window:20000= 0
     a=3Dssrc:1234
     a=3Dssrc:2345
     a=3Dssrc:3456
     a=3Dssrc:4567
     a=3Dssrc-group:FID 1234 2345
     a=3Dssrc-group:FEC-FR 1234 3456 4567

SSRC 1234 is the primary encoding (VP8 or VP9)
SSRC 2345 is RTX (either PT 108 or 109, as needed)
SSRC 3456 is FEC (either PT 110 or 111, depending on impl)
SSRC 4567 is FEC (either PT 110 or 111, depending on impl)


On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Mari= di Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
>
> Makaraju, Maridi Raju (Raju) wrote:
> > OPUS does have a built-in FEC so no need for red+ulpfec.
>
> As discussed previously on this list [1] the built-in FEC only covers<= br> > the SILK layer. Existing codec-agnostic mechanisms were perfectly
> adequate for protecting CELT-mode packets, so we didn't invent somethi= ng
> new.
>
> [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html
[Raju] Thanks and appreciate the reference.

_______________________________________________
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_D075F3CB3D2D6mzanatyciscocom_-- From nobody Tue Oct 28 23:02:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDFA1A0262 for ; Tue, 28 Oct 2014 23:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.002 X-Spam-Level: * X-Spam-Status: No, score=1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_41=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozaZFX7wjFbE for ; Tue, 28 Oct 2014 23:02:13 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DD31A0242 for ; Tue, 28 Oct 2014 23:02:13 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id g10so2326102pdj.10 for ; Tue, 28 Oct 2014 23:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=4dINoz0ryNrWQxChV0cqUrEW0ikBhvlHtg4kv9TsH7w=; b=jxgsh5vXRKBy6h2IRPrEM/OJ0pOclROVbgFy0ZUcVhaKngCRV3CRvPeMI6oNn5+9mp AfccFk9h5RKX0KQcsKrnOeog4nFKh/B1v2xYVyPasW8XJOQ2rof15WNUnOJc0b+0uxb/ NHohmTo5M3vUtultPgTdHxWX21gq+kb2hCxf+1X9xcSwFDwPWon/eOmVjronlda9tbMz twLBTfj/BLs5qWCRvc79uae2YRnEmkaroTB1eOGTYH8uoESnFMGtmFGEoG07aQTjugin J9kDVok3FamKijew/wiCxQlWcV5ALBswOLdiNTVVUQRPbUtn/An1Zi2MVXJesMS84FD2 gDFQ== X-Received: by 10.66.119.70 with SMTP id ks6mr8429869pab.74.1414562532604; Tue, 28 Oct 2014 23:02:12 -0700 (PDT) Received: from [192.168.1.129] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by mx.google.com with ESMTPSA id cl1sm3203029pbb.92.2014.10.28.23.02.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 23:02:11 -0700 (PDT) References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> <544936E5.2040909@mozilla.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-11DC9C59-791F-486A-A422-09DFC5A3F510 Content-Transfer-Encoding: 7bit Message-Id: <2442DC48-D91D-4802-A140-251FC15E4CD9@gmail.com> X-Mailer: iPhone Mail (12B411) From: Bernard Aboba Date: Tue, 28 Oct 2014 23:02:09 -0700 To: "Mo Zanaty (mzanaty)" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YE0J66YdjPZoYInsVoCQQxsx4i8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 06:02:15 -0000 --Apple-Mail-11DC9C59-791F-486A-A422-09DFC5A3F510 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am not against allowing 'apt' with FEC, but forcing a PT to be consumed for e= ach FEC stream could get out of hand, particularly for combined simulcast/SV= C cases.=20 > On Oct 28, 2014, at 10:51 PM, Mo Zanaty (mzanaty) wrot= e: >=20 > I think Justin meant the =E2=80=9Cinitial SSRC=E2=80=9D in the a=3Dssrc-gr= oup lines carries significance (as the source), not the order of a=3Dssrc li= nes. >=20 > What if new FEC schemes defined for bundle / unified plan (such as those b= elow) followed the example of RTX by including apt=3D100 in their fmtp param= eters? So PT can be used to associate source and FEC flows without declaring= any SSRCs or groups. >=20 > We can also improve on RTX by allowing apt=3D100,101 for FEC. >=20 > When we consider more complex cases like RTX/FEC with simulcast and scalab= le streams in unified plan, using PT association may be better than declarin= g many SSRCs (which is also problematic in cases of collisions, dynamic sour= ces, switching mixers, etc.). >=20 > Mo >=20 >=20 > On 10/29/14, 1:22 AM, Martin Thomson wrote: > Sounds like a reasonable idea to me, but don't you have to specify a stric= t pecking order? RTX before FEC doesn't sound right to me, but that's pure p= rejudice/bias (FEC is always present, and optional stuff his last) > So how would you decide that order? A hat? PT value? Order of PT on the m l= ine? Order of the fmtp attributes? Something else? Or can we simply fix the o= rder, since there are only a small number of variations to consider? >=20 >> On Oct 28, 2014 9:24 PM, "Justin Uberti" wrote: >> So it's not clear to me that a=3Dssrc:X fmtp:Y is actually legal, without= any fmtp parameters, or that it clearly indicates that only PT Y is to be s= ent on that SSRC. As such, I consider this solution to be wishful thinking. >>=20 >> I think it would be easier if we defined FEC/FID semantics such that the i= nitial SSRC was to be used for the primary encoding, and any subsequent SSRC= s were used for the secondary/tertiary streams. (e.g. RTX or FEC) >>=20 >> e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC: >> =20 >> m=3Dvideo 30000 RTP/AVP 100 101 108 109 110 111 >> c=3DIN IP4 233.252.0.1 >> a=3Drtpmap:100 VP8/90000 >> a=3Drtpmap:101 VP9/90000 >> a=3Drtpmap:108 rtx/90000 >> a=3Drtpmap:109 rtx/90000 >> a=3Dfmtp:108 apt=3D100 >> a=3Dfmtp:109 apt=3D101 >> a=3Drtpmap:110 interleaved-parityfec/90000 >> a=3Dfmtp:110 L:5; D:10; ToP:2; repair-window:200000 >> a=3Drtpmap:111 non-interleaved-parityfec/90000 >> a=3Dfmtp:111 L:5; D:10; ToP:2; repair-window:200000 >> a=3Dssrc:1234 >> a=3Dssrc:2345 >> a=3Dssrc:3456 >> a=3Dssrc:4567 >> a=3Dssrc-group:FID 1234 2345 >> a=3Dssrc-group:FEC-FR 1234 3456 4567 >>=20 >> SSRC 1234 is the primary encoding (VP8 or VP9) >> SSRC 2345 is RTX (either PT 108 or 109, as needed) >> SSRC 3456 is FEC (either PT 110 or 111, depending on impl) >> SSRC 4567 is FEC (either PT 110 or 111, depending on impl) >>=20 >>=20 >>> On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) wrote: >>> > >>> > Makaraju, Maridi Raju (Raju) wrote: >>> > > OPUS does have a built-in FEC so no need for red+ulpfec. >>> > >>> > As discussed previously on this list [1] the built-in FEC only covers >>> > the SILK layer. Existing codec-agnostic mechanisms were perfectly >>> > adequate for protecting CELT-mode packets, so we didn't invent somethi= ng >>> > new. >>> > >>> > [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html= >>> [Raju] Thanks and appreciate the reference. >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail-11DC9C59-791F-486A-A422-09DFC5A3F510 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Am not against allowing 'apt' with FEC= , but forcing a PT to be consumed for each FEC stream could get out of hand,= particularly for combined simulcast/SVC cases. 


=
On Oct 28, 2014, at 10:51 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

I think Justin meant the =E2=80=9Cinitial SSRC=E2=80=9D in the a=3Dssrc= -group lines carries significance (as the source), not the order of a=3Dssrc= lines.

What if new FEC schemes defined for bundle / unified plan (such as thos= e below) followed the example of RTX by including apt=3D100 in their fmtp pa= rameters? So PT can be used to associate source and FEC flows without declar= ing any SSRCs or groups.

We can also improve on RTX by allowing apt=3D100,101 for FEC.

When we consider more complex cases like RTX/FEC with simulcast and sca= lable streams in unified plan, using PT association may be better than decla= ring many SSRCs (which is also problematic in cases of collisions, dynamic s= ources, switching mixers, etc.).

Mo


On 10/29/14, 1:22 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
Sounds like a reasonable idea to me, but don't you have to specify a st= rict pecking order? RTX before FEC doesn't sound right to me, but that's pur= e prejudice/bias (FEC is always present, and optional stuff his last)

So how would you decide that order? A hat? PT value? Order of= PT on the m line? Order of the fmtp attributes? Something else? Or can we s= imply fix the order, since there are only a small number of variations to co= nsider?

On Oct 28, 2014 9:24 PM, "Justin Uberti" <juberti@google.com> wrote:
So it's not clear to me that a=3Dssrc:X fmtp:Y is actually l= egal, without any fmtp parameters, or that it clearly indicates that only PT= Y is to be sent on that SSRC. As such, I consider this solution to be wishf= ul thinking.

I think it would be easier if we defined FEC/FID semantics such that th= e initial SSRC was to be used for the primary encoding, and any subsequent S= SRCs were used for the secondary/tertiary streams. (e.g. RTX or FEC)

e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC:
  
     m=3Dvideo 30000 RTP/AVP 100 101 108 109 110 111
=
     c=3DIN IP4 233.252.0.1
     a=3Drtpmap:100 VP8/90000
     a=3Drtpmap:101 VP9/90000
     a=3Drtpmap:108 rtx/90000
     a=3Drtpmap:109 rtx/90000
     a=3Dfmtp:108 apt=3D100
     a=3Dfmtp:109 apt=3D101
     a=3Drtpmap:110 interleaved-parityfec/90000
     a=3Dfmtp:110 L:5; D:10; ToP:2; repair-window:200000=
     a=3Drtpmap:111 non-interleaved-parityfec/90000
     a=3Dfmtp:111 L:5; D:10; ToP:2; repair-window:200000=
     a=3Dssrc:1234
     a=3Dssrc:2345
     a=3Dssrc:3456
     a=3Dssrc:4567
     a=3Dssrc-group:FID 1234 2345
     a=3Dssrc-group:FEC-FR 1234 3456 4567

SSRC 1234 is the primary encoding (VP8 or VP9)
SSRC 2345 is RTX (either PT 108 or 109, as needed)
SSRC 3456 is FEC (either PT 110 or 111, depending on impl)
SSRC 4567 is FEC (either PT 110 or 111, depending on impl)


On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Marid= i Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
>
> Makaraju, Maridi Raju (Raju) wrote:
> > OPUS does have a built-in FEC so no need for red+ulpfec.
>
> As discussed previously on this list [1] the built-in FEC only covers > the SILK layer. Existing codec-agnostic mechanisms were perfectly
> adequate for protecting CELT-mode packets, so we didn't invent somethin= g
> new.
>
> [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html
[Raju] Thanks and appreciate the reference.

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


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtcweb
____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-11DC9C59-791F-486A-A422-09DFC5A3F510-- From nobody Tue Oct 28 23:54:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444591A0861 for ; Tue, 28 Oct 2014 23:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYPgDIDlil1t for ; Tue, 28 Oct 2014 23:54:37 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFD61A1B44 for ; Tue, 28 Oct 2014 23:54:36 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-30-54508f29df12 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D7.6D.04387.92F80545; Wed, 29 Oct 2014 07:54:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 07:54:33 +0100 From: Christer Holmberg To: Martin Thomson , Justin Uberti Thread-Topic: [rtcweb] SDP and ssrc-group, Thread-Index: AQHP7Uu53ORuYUmhZEGnT/U2XfLaS5w6rXKAgAACuQCAAASUgIAACu4AgAGZaoCAAAsdAIAAXy2AgAEHC4CAAAJlgIAAJkEAgAiBxwCAABB1AIAAKTCw Date: Wed, 29 Oct 2014 06:54:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D2633@ESESSMB209.ericsson.se> References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> <544936E5.2040909@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4D2633ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3RlerPyDEoO+msMXWqUIW1878Y7RY +6+d3YHZY+esu+weCzaVeixZ8pMpgDmKyyYlNSezLLVI3y6BK2Pv1rfsBR9aGSuWrJzM2MC4 pImxi5GTQ0LAROL93/XMELaYxIV769m6GLk4hASOMErcWbELylnCKHHqyiyWLkYODjYBC4nu f9ogDSICwRK3jt4Fa2YWUJe4s/gcO4gtLKApsebkQyaIGi2JZf96GUHmiAg0MUrc37aPDSTB IqAq8ez/O7AGXgFfiSffWllAbCGBTWwSLzdHgeziFAiUWNhfBRJmBDru+6k1TBC7xCVuPZnP BHG0gMSSPeehHhCVePn4HytIq4SAosTyfjmI8nyJ5113oTYJSpyc+YRlAqPoLCSTZiEpm4Wk bBbQJGagb9bv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OLi3HQjI73Uoszk4uL8PL28 1JJNjMD4O7jlt9UOxoPPHQ8xCnAwKvHwbmDzDxFiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYwccapH8hYuOWc82S/g3+87Hb3WVXEPf7fEvK2o54/J2pFw d+uvYqHDO09kKqgUdUvHljyr8Vle06A17W1/bdiK+DMJyX8OPs48L53xI/TL/OUMOzYqBU3l uhnm/XfXiigpK4fMyAt5Hvav91rv4vbpcl/qu/D44a9/9HZ9t5+yLjH1Z7yF5jclluKMREMt 5qLiRABTkCAQoAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/56qm1C8tadBsELcEUMWwPtXjqDU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 06:54:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4D2633ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5Tb3VuZHMgbGlrZSBhIHJlYXNvbmFibGUgaWRlYSB0byBtZSwgYnV0IGRvbid0IHlv dSBoYXZlIHRvIHNwZWNpZnkgYSBzdHJpY3QgcGVja2luZyBvcmRlcj8gUlRYIGJlZm9yZSBGRUMg ZG9lc24ndCBzb3VuZCByaWdodCB0byBtZSwgYnV0IHRoYXQncyBwdXJlIHByZWp1ZGljZS9iaWFz IChGRUMgaXMgYWx3YXlzIHByZXNlbnQsIGFuZCBvcHRpb25hbCBzdHVmZiBoaXMgbGFzdCkNCj4N Cj5TbyBob3cgd291bGQgeW91IGRlY2lkZSB0aGF0IG9yZGVyPyBBIGhhdD8gUFQgdmFsdWU/IE9y ZGVyIG9mIFBUIG9uIHRoZSBtIGxpbmU/IE9yZGVyIG9mIHRoZSBmbXRwIGF0dHJpYnV0ZXM/IFNv bWV0aGluZyBlbHNlPyBPciBjYW4gd2Ugc2ltcGx5IGZpeCB0aGUgb3JkZXIsIHNpbmNlIHRoZXJl IGFyZSBvbmx5IGEgc21hbGwgbnVtYmVyIG9mIHZhcmlhdGlvbnMgdG8gY29uc2lkZXI/DQoNCldp dGhvdXQgY29tbWVudGluZyBvbiB0aGlzIHNwZWNpZmljIG1lY2hhbmlzbSwgaW4gZ2VuZXJhbCB3 ZSBzaG91bGQgTk9UIGRlZmluZSBzb2x1dGlvbnMgd2hpY2ggYXNzdW1lIGEgY2VydGFpbiBvcmRl ciBvZiBhdHRyaWJ1dGVzIChhc3NvY2lhdGVkIHdpdGggYSBnaXZlbiBtLSBsaW5lLCBvciBvbiBz ZXNzaW9uIGxldmVsKSBldGMuDQoNCkkgaGF2ZSBzZWVuIG5vZGVzLCB3aGVyZSB0aGUgb3JkZXIg b2YgYXR0cmlidXRlcyBoYXMgY2hhbmdlZCBiZXR3ZWVuIHRoZSBpbmNvbWluZy0gYW5kIG91dGdv aW5nIFNEUCwgZHVlIHRvIHRoZSB3YXkgdGhlIHBhcnNlciBpbiB0aGUgbm9kZSBpcyBpbXBsZW1l bnRlZC4NCg0KSSBhbHNvIGRvbuKAmXQgdGhpbmsgd2Ugc2hvdWxkIGNoYW5nZSB0aGUgc2VtYW50 aWNzIG9mIHRoZSBQVCBvcmRlciBpbiB0aGUgbS0gbGluZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KDQoNCg0KDQoNCk9uIE9jdCAyOCwgMjAxNCA5OjI0IFBNLCAiSnVzdGluIFViZXJ0aSIg PGp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQpT byBpdCdzIG5vdCBjbGVhciB0byBtZSB0aGF0IGE9c3NyYzpYIGZtdHA6WSBpcyBhY3R1YWxseSBs ZWdhbCwgd2l0aG91dCBhbnkgZm10cCBwYXJhbWV0ZXJzLCBvciB0aGF0IGl0IGNsZWFybHkgaW5k aWNhdGVzIHRoYXQgb25seSBQVCBZIGlzIHRvIGJlIHNlbnQgb24gdGhhdCBTU1JDLiBBcyBzdWNo LCBJIGNvbnNpZGVyIHRoaXMgc29sdXRpb24gdG8gYmUgd2lzaGZ1bCB0aGlua2luZy4NCg0KSSB0 aGluayBpdCB3b3VsZCBiZSBlYXNpZXIgaWYgd2UgZGVmaW5lZCBGRUMvRklEIHNlbWFudGljcyBz dWNoIHRoYXQgdGhlIGluaXRpYWwgU1NSQyB3YXMgdG8gYmUgdXNlZCBmb3IgdGhlIHByaW1hcnkg ZW5jb2RpbmcsIGFuZCBhbnkgc3Vic2VxdWVudCBTU1JDcyB3ZXJlIHVzZWQgZm9yIHRoZSBzZWNv bmRhcnkvdGVydGlhcnkgc3RyZWFtcy4gKGUuZy4gUlRYIG9yIEZFQykNCg0KZS5nLiBmb3IgYSBz dHJlYW0gd2l0aCAyIHZpZGVvIGNvZGVjcywgUlRYIGFuZCAxZC8yZCBGRUM6DQoNCiAgICAgbT12 aWRlbyAzMDAwMCBSVFAvQVZQIDEwMCAxMDEgMTA4IDEwOSAxMTAgMTExDQogICAgIGM9SU4gSVA0 IDIzMy4yNTIuMC4xDQogICAgIGE9cnRwbWFwOjEwMCBWUDgvOTAwMDANCiAgICAgYT1ydHBtYXA6 MTAxIFZQOS85MDAwMA0KICAgICBhPXJ0cG1hcDoxMDggcnR4LzkwMDAwDQogICAgIGE9cnRwbWFw OjEwOSBydHgvOTAwMDANCiAgICAgYT1mbXRwOjEwOCBhcHQ9MTAwDQogICAgIGE9Zm10cDoxMDkg YXB0PTEwMQ0KICAgICBhPXJ0cG1hcDoxMTAgaW50ZXJsZWF2ZWQtcGFyaXR5ZmVjLzkwMDAwDQog ICAgIGE9Zm10cDoxMTAgTDo1OyBEOjEwOyBUb1A6MjsgcmVwYWlyLXdpbmRvdzoyMDAwMDANCiAg ICAgYT1ydHBtYXA6MTExIG5vbi1pbnRlcmxlYXZlZC1wYXJpdHlmZWMvOTAwMDANCiAgICAgYT1m bXRwOjExMSBMOjU7IEQ6MTA7IFRvUDoyOyByZXBhaXItd2luZG93OjIwMDAwMA0KICAgICBhPXNz cmM6MTIzNA0KICAgICBhPXNzcmM6MjM0NQ0KICAgICBhPXNzcmM6MzQ1Ng0KICAgICBhPXNzcmM6 NDU2Nw0KICAgICBhPXNzcmMtZ3JvdXA6RklEIDEyMzQgMjM0NQ0KICAgICBhPXNzcmMtZ3JvdXA6 RkVDLUZSIDEyMzQgMzQ1NiA0NTY3DQoNClNTUkMgMTIzNCBpcyB0aGUgcHJpbWFyeSBlbmNvZGlu ZyAoVlA4IG9yIFZQOSkNClNTUkMgMjM0NSBpcyBSVFggKGVpdGhlciBQVCAxMDggb3IgMTA5LCBh cyBuZWVkZWQpDQpTU1JDIDM0NTYgaXMgRkVDIChlaXRoZXIgUFQgMTEwIG9yIDExMSwgZGVwZW5k aW5nIG9uIGltcGwpDQpTU1JDIDQ1NjcgaXMgRkVDIChlaXRoZXIgUFQgMTEwIG9yIDExMSwgZGVw ZW5kaW5nIG9uIGltcGwpDQoNCg0KT24gVGh1LCBPY3QgMjMsIDIwMTQgYXQgMTI6MjkgUE0sIE1h a2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgPFJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQu Y29tPG1haWx0bzpSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdyb3RlOg0KPg0K PiBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIHdyb3RlOg0KPiA+IE9QVVMgZG9lcyBoYXZl IGEgYnVpbHQtaW4gRkVDIHNvIG5vIG5lZWQgZm9yIHJlZCt1bHBmZWMuDQo+DQo+IEFzIGRpc2N1 c3NlZCBwcmV2aW91c2x5IG9uIHRoaXMgbGlzdCBbMV0gdGhlIGJ1aWx0LWluIEZFQyBvbmx5IGNv dmVycw0KPiB0aGUgU0lMSyBsYXllci4gRXhpc3RpbmcgY29kZWMtYWdub3N0aWMgbWVjaGFuaXNt cyB3ZXJlIHBlcmZlY3RseQ0KPiBhZGVxdWF0ZSBmb3IgcHJvdGVjdGluZyBDRUxULW1vZGUgcGFj a2V0cywgc28gd2UgZGlkbid0IGludmVudCBzb21ldGhpbmcNCj4gbmV3Lg0KPg0KPiBbMV0gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMjM1 My5odG1sDQpbUmFqdV0gVGhhbmtzIGFuZCBhcHByZWNpYXRlIHRoZSByZWZlcmVuY2UuDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFp bGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QN CnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== --_000_7594FB04B1934943A5C02806D1A2204B1D4D2633ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0 Ozwvc3Bhbj5Tb3VuZHMgbGlrZSBhIHJlYXNvbmFibGUgaWRlYSB0byBtZSwgYnV0IGRvbid0IHlv dSBoYXZlIHRvIHNwZWNpZnkgYSBzdHJpY3QgcGVja2luZyBvcmRlcj8gUlRYIGJlZm9yZSBGRUMg ZG9lc24ndCBzb3VuZCByaWdodCB0byBtZSwgYnV0IHRoYXQncyBwdXJlIHByZWp1ZGljZS9iaWFz IChGRUMgaXMgYWx3YXlzIHByZXNlbnQsIGFuZCBvcHRpb25hbCBzdHVmZiBoaXMgbGFzdCk8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PGJyPg0KJmd0Ozxicj4NCiZndDs8L3NwYW4+U28gaG93 IHdvdWxkIHlvdSBkZWNpZGUgdGhhdCBvcmRlcj8gQSBoYXQ/IFBUIHZhbHVlPyBPcmRlciBvZiBQ VCBvbiB0aGUgbSBsaW5lPyBPcmRlciBvZiB0aGUgZm10cCBhdHRyaWJ1dGVzPyBTb21ldGhpbmcg ZWxzZT8gT3IgY2FuIHdlIHNpbXBseSBmaXggdGhlIG9yZGVyLCBzaW5jZSB0aGVyZSBhcmUgb25s eSBhIHNtYWxsIG51bWJlciBvZiB2YXJpYXRpb25zIHRvIGNvbnNpZGVyPzxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2l0aG91dCBjb21tZW50aW5nIG9uIHRoaXMgc3Bl Y2lmaWMgbWVjaGFuaXNtLCBpbiBnZW5lcmFsIHdlIHNob3VsZCBOT1QgZGVmaW5lIHNvbHV0aW9u cyB3aGljaCBhc3N1bWUgYSBjZXJ0YWluIG9yZGVyIG9mIGF0dHJpYnV0ZXMgKGFzc29jaWF0ZWQg d2l0aCBhIGdpdmVuIG0tIGxpbmUsIG9yIG9uIHNlc3Npb24NCiBsZXZlbCkgZXRjLiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBoYXZlIHNlZW4gbm9kZXMsIHdoZXJlIHRoZSBvcmRlciBvZiBhdHRyaWJ1dGVzIGhh cyBjaGFuZ2VkIGJldHdlZW4gdGhlIGluY29taW5nLSBhbmQgb3V0Z29pbmcgU0RQLCBkdWUgdG8g dGhlIHdheSB0aGUgcGFyc2VyIGluIHRoZSBub2RlIGlzIGltcGxlbWVudGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIGFsc28gZG9u4oCZdCB0aGluayB3ZSBzaG91bGQgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2Yg dGhlIFBUIG9yZGVyIGluIHRoZSBtLSBsaW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBPY3QgMjgsIDIwMTQgOToyNCBQTSwgJnF1b3Q7SnVzdGluIFViZXJ0aSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSI+anViZXJ0aUBnb29nbGUu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U28gaXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCBhPXNzcmM6WCBmbXRwOlkgaXMgYWN0 dWFsbHkgbGVnYWwsIHdpdGhvdXQgYW55IGZtdHAgcGFyYW1ldGVycywgb3IgdGhhdCBpdCBjbGVh cmx5IGluZGljYXRlcyB0aGF0IG9ubHkgUFQgWSBpcyB0byBiZSBzZW50IG9uIHRoYXQgU1NSQy4g QXMgc3VjaCwgSSBjb25zaWRlciB0aGlzIHNvbHV0aW9uIHRvIGJlIHdpc2hmdWwgdGhpbmtpbmcu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0 IHdvdWxkIGJlIGVhc2llciBpZiB3ZSBkZWZpbmVkIEZFQy9GSUQgc2VtYW50aWNzIHN1Y2ggdGhh dCB0aGUgaW5pdGlhbCBTU1JDIHdhcyB0byBiZSB1c2VkIGZvciB0aGUgcHJpbWFyeSBlbmNvZGlu ZywgYW5kIGFueSBzdWJzZXF1ZW50IFNTUkNzIHdlcmUgdXNlZCBmb3IgdGhlIHNlY29uZGFyeS90 ZXJ0aWFyeSBzdHJlYW1zLiAoZS5nLiBSVFggb3IgRkVDKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lLmcuIGZvciBhIHN0cmVhbSB3aXRoIDIg dmlkZW8gY29kZWNzLCBSVFggYW5kIDFkLzJkIEZFQzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7bT12aWRlbyAzMDAwMCBSVFAvQVZQIDEwMCAxMDEgMTA4IDEwOSAxMTAgMTExPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7ICZuYnNwO2M9SU4gSVA0IDIzMy4yNTIuMC4xPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2E9cnRwbWFwOjEw MCBWUDgvOTAwMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7YT1ydHBtYXA6MTAxIFZQOS85MDAwMDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDthPXJ0cG1hcDoxMDggcnR4LzkwMDAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2E9cnRwbWFwOjEw OSBydHgvOTAwMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7YT1mbXRwOjEwOCBhcHQ9MTAwPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZu YnNwO2E9Zm10cDoxMDkgYXB0PTEwMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXJ0cG1hcDoxMTAgaW50ZXJs ZWF2ZWQtcGFyaXR5ZmVjLzkwMDAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2E9Zm10cDoxMTAgTDo1OyBEOjEw OyBUb1A6MjsgcmVwYWlyLXdpbmRvdzoyMDAwMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7YT1ydHBtYXA6MTEx IG5vbi1pbnRlcmxlYXZlZC1wYXJpdHlmZWMvOTAwMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7YT1mbXRwOjEx MSBMOjU7IEQ6MTA7IFRvUDoyOyByZXBhaXItd2luZG93OjIwMDAwMDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDth PXNzcmM6MTIzNDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXNzcmM6MjM0NTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXNz cmM6MzQ1NjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXNzcmM6NDU2NzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXNzcmMt Z3JvdXA6RklEIDEyMzQgMjM0NTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXNzcmMtZ3JvdXA6RkVDLUZSIDEy MzQgMzQ1NiA0NTY3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U1NSQyAxMjM0IGlzIHRoZSBwcmltYXJ5IGVuY29kaW5nIChWUDgg b3IgVlA5KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U1NSQyAyMzQ1IGlzIFJUWCAoZWl0aGVyIFBUIDEwOCBvciAxMDksIGFzIG5lZWRlZCk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNTUkMgMzQ1 NiBpcyBGRUMgKGVpdGhlciBQVCAxMTAgb3IgMTExLCBkZXBlbmRpbmcgb24gaW1wbCk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNTUkMgNDU2NyBp cyBGRUMgKGVpdGhlciBQVCAxMTAgb3IgMTExLCBkZXBlbmRpbmcgb24gaW1wbCk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE9j dCAyMywgMjAxNCBhdCAxMjoyOSBQTSwgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8YnI+DQomZ3Q7IE1ha2Fy YWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IE9QVVMgZG9lcyBo YXZlIGEgYnVpbHQtaW4gRkVDIHNvIG5vIG5lZWQgZm9yIHJlZCYjNDM7dWxwZmVjLjxicj4NCiZn dDs8YnI+DQomZ3Q7IEFzIGRpc2N1c3NlZCBwcmV2aW91c2x5IG9uIHRoaXMgbGlzdCBbMV0gdGhl IGJ1aWx0LWluIEZFQyBvbmx5IGNvdmVyczxicj4NCiZndDsgdGhlIFNJTEsgbGF5ZXIuIEV4aXN0 aW5nIGNvZGVjLWFnbm9zdGljIG1lY2hhbmlzbXMgd2VyZSBwZXJmZWN0bHk8YnI+DQomZ3Q7IGFk ZXF1YXRlIGZvciBwcm90ZWN0aW5nIENFTFQtbW9kZSBwYWNrZXRzLCBzbyB3ZSBkaWRuJ3QgaW52 ZW50IHNvbWV0aGluZzxicj4NCiZndDsgbmV3Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFsxXSA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50 L21zZzEyMzUzLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMTIzNTMuaHRtbDwvYT48YnI+DQpbUmFq dV0gVGhhbmtzIGFuZCBhcHByZWNpYXRlIHRoZSByZWZlcmVuY2UuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3 ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K cnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci PnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D4D2633ESESSMB209erics_-- From nobody Wed Oct 29 00:48:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195701A6F5B for ; Wed, 29 Oct 2014 00:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TaX3OsALpB6 for ; Wed, 29 Oct 2014 00:48:10 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C7B1A1B73 for ; Wed, 29 Oct 2014 00:48:09 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id l18so2643550wgh.10 for ; Wed, 29 Oct 2014 00:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=iI8cp2E6t1q2AWoNdiMUNPb0jvl2+kOlD6PQoDdfJgo=; b=e7qghg/egrCtgTszKjETh4JLTof/vUU+8a3iKDasP1hPSv4u0Q51sSxIXBii5oUPGg Zc5Pen8OHKe/QODSJbaqNxTJEwdtTHWevx42bEgKahXn5wwXMbQys/5sgm5c2BLbMXuz izVpttzoDlKuRQdx8J4Jt77RDjd/pIox0HtK3NJn+OFD9XecxVTZ4GclA9JoRdorFbHR wOMjtkRXz4DIhAB6N3j/CvhPqzPpEFcGMp/r+IPIYWQnA2i7c4mf6EHdOSxZU5rhU0QX WCDvJvTxetMdzFHWfSGQ+56gEdVKLx9V6/nyPAQmp7fgo2wb6mflfPKWTNU55JEZtF2k ojnw== X-Received: by 10.180.211.2 with SMTP id my2mr10724935wic.13.1414568888524; Wed, 29 Oct 2014 00:48:08 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id cw6sm4268222wjb.18.2014.10.29.00.48.05 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Oct 2014 00:48:07 -0700 (PDT) From: "Roni Even" To: =?utf-8?Q?'I=C3=B1aki_Baz_Castillo'?= , References: In-Reply-To: Date: Wed, 29 Oct 2014 09:48:00 +0200 Message-ID: <095701cff34c$ad1089c0$07319d40$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIdm2glshlU301gGbh4Wgrmbmu/a5urYfsA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FHIzv2sbjhJTKznWaFQRvJjBACk Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 07:48:12 -0000 Hi, We discussed this mapping issue in a previous version of the application = token draft = http://tools.ietf.org/html/draft-even-mmusic-application-token-02 = example in section 1. We thought of having a mapping from appId to "pt" (section 3.3.1) Roni > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of I?aki Baz = Castillo > Sent: 21 October, 2014 7:26 PM > To: rtcweb@ietf.org > Subject: [rtcweb] SDP and ssrc-group, >=20 > Hi, >=20 > May I know which SSRC (345259865 or 2693756249) will be used for the = real > media stream (plus RED and FEC) and which SSRC will be used for RTX? >=20 >=20 >=20 > -------------------------- > m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 > a=3Dmid:video > a=3Drtpmap:100 VP8/90000 > a=3Drtpmap:116 red/90000 > a=3Drtpmap:117 ulpfec/90000 > a=3Drtpmap:96 rtx/90000 > a=3Dfmtp:96 apt=3D100 > a=3Dssrc-group:FID 345259865 2693756249 > a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs > a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs > a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > c0134f05-e7c2-4afd-a979-4e224de5eb91 > a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5 > a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91 > ------------------------------- >=20 >=20 >=20 >=20 > RFC 5576 does not clarify it at all: >=20 > http://tools.ietf.org/html/rfc5576#section-4.2 >=20 > -------------------------------------------------- > 4.2. The "ssrc-group" Media Attribute >=20 > a=3Dssrc-group: ... >=20 > [..] >=20 > The parameter is taken from the specification of the > "group" attribute [RFC3388]. The initial semantic values defined = for > the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] > and FEC (Forward Error Correction) [RFC4756]. In each case, the > relationship among the grouped sources is the same as the > relationship among corresponding sources in media streams grouped > using the SDP "group" attribute. > -------------------------------------------------- >=20 >=20 >=20 > The referenced RFC 3388 neither clarifies it: >=20 > --------------------------------------------------- > 7.4 FID Semantics >=20 > Several "m" lines grouped together using FID semantics form a media > flow. A media agent handling a media flow that comprises several = "m" > lines MUST send a copy of the media to every "m" line part of the > flow as long as the codecs and the direction attribute present in a > particular "m" line allow it. >=20 > It is assumed that the application uses only one codec at a time to > encode the media produced. This codec MAY change dynamically = during > the session, but at any particular moment only one codec is in use. >=20 > The application encodes the media using the current codec and = checks > one by one all the "m" lines that are part of the flow. If a > particular "m" line contains the codec being used and the direction > attribute is "sendonly" or "sendrecv", a copy of the encoded media = is > sent to the address/port specified in that particular media stream. > If either the "m" line does not contain the codec being used or the > direction attribute is neither "sendonly" nor "sendrecv", nothing = is > sent over this media stream. > ---------------------------------------------------- >=20 >=20 >=20 >=20 > So, how is the usage of ssrc-group? Where is it really defined? >=20 > Can I put more than 2 ssrc together in the same ssrc-group line? >=20 > How should the receiver interpret it? >=20 > Does a ssrc-group always mean RTX usage? Where is that specified in = the > above SDP? >=20 > Does not the above SDP look a complete mixture of hacks and = workarounds? >=20 >=20 >=20 >=20 > -- > I=C3=B1aki Baz Castillo > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Oct 29 02:11:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905941A6FF4 for ; Wed, 29 Oct 2014 02:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4P9pz1HYxOh for ; Wed, 29 Oct 2014 02:11:38 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F5A1A6FF3 for ; Wed, 29 Oct 2014 02:11:37 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id l4so2096235lbv.28 for ; Wed, 29 Oct 2014 02:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jYeF7xMBaz2dYarCP3dqcB4sxfINbZF9hGQn90vfGhg=; b=RTXhEuzHb0cAzTAJZo4CyN8wO3uCb02wTRp0RYH1PYajLKSpjfgvPEfclAWJU65KID rXyJE4ydI4pZSweFLkZg21NPqv8GbxBFwcjunT684W4vF1OUiNoWQTWrYO9UNrUYjrPV BO8HegQllOufSTGDVwz4VciwiWb/Xzy30bIV+na0yBjET/Twu5Xe+s8Q6EUPfBIKdcys MfNdJu57t0AepfSx7hTPd5QtLJr9PvIJZuyNB6enWILWHX4DvZXPHCbbjHT1qtb40JaN 0n9cP9NGc+0WSNMm2vvsugWXsajtK+dUxQX87T4Q2sMf7iAtn/i+QZtTE+Sm9kADvrWj zLtw== MIME-Version: 1.0 X-Received: by 10.112.47.37 with SMTP id a5mr9858212lbn.31.1414573896076; Wed, 29 Oct 2014 02:11:36 -0700 (PDT) Received: by 10.25.77.73 with HTTP; Wed, 29 Oct 2014 02:11:36 -0700 (PDT) Date: Wed, 29 Oct 2014 10:11:36 +0100 Message-ID: From: Victor Pascual Avila To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GdmbJdVAGB5N0gKxb8HAsqnFJds Subject: [rtcweb] draft agenda for rtcweb at ietf91? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 09:11:39 -0000 Dear chairs, where could I find the draft agenda for the upcoming meeting? Thanks in advance, -Victor From nobody Wed Oct 29 03:05:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1E21A8032 for ; Wed, 29 Oct 2014 03:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4zDzIIwdIHz for ; Wed, 29 Oct 2014 03:05:30 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5411A70E1 for ; Wed, 29 Oct 2014 03:05:30 -0700 (PDT) Received: from [192.168.1.200] (p508F31C9.dip0.t-ipconnect.de [80.143.49.201]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 2CAD11C1050FB; Wed, 29 Oct 2014 11:05:27 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> Date: Wed, 29 Oct 2014 11:05:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8CA6F4DE-8978-458B-9C77-21CFA33C48CE@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se> , <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> To: "Mo Zanaty (mzanaty)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9cHcqDJvxEj6n7s1H5A9_m4rtF8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 10:05:42 -0000 On 28 Oct 2014, at 23:28, Mo Zanaty (mzanaty) wrote: > On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" = wrote: >=20 > On 28 Oct 2014, at 21:52, Mo Zanaty (mzanaty) = wrote: >=20 >>> What resource is being conserved by not just requiring it? >>=20 >> 8 bytes per packet (for MID+FSN). >>=20 >> Michael, the current NDATA draft requires it to be used for all = messages if negotiated. Can=92t this be relaxed / optimized to use it = for all *fragmented* messages but use DATA for non-fragmented messages = to avoid the 8 byte overhead for small messages (like game = telemetry/control, an often cited use of data channels). > You can bring this up at the tsvwg mailing list. >=20 > Mo: Will do. >=20 > However, we normally do not optimize for byte saving... Mixing > both makes the processing harder... Maybe we can use a bit in the = flags to indicate if the additional fields are > there... >=20 > Mo: Type should already be enough without flags. >=20 >>=20 >> The current NDATA draft also says you can=92t interleave fragmented = messages in a stream, so head of line blocking remains for all = fragmented messages, while only small non-fragmented messages can avoid = it. This dilutes the utility of NDATA, perhaps enough to make apps that = really care about head of line blocking to implement their own app layer = fragmentation with messages well below common MTUs, hence defeating = NDATA. Can=92t this also be relaxed since MID is part of the NDATA extra = header? > This would only make sense for messages marked as unordered... For = ordered it doesn't make sense. >=20 > Mo: The restriction applies to unordered as well as ordered. Even for = ordered, it does make sense to avoid head of line blocking at the = sender.=20 I don't understand how you can do it for ordered. The sender sends a = large message on stream 0 and after that a small on stream zero. For both ordered delivery is request. So the = receiver can't deliver the second before the first. >>=20 >> If those two issues are resolved, I see no argument against making = NDATA a MUST in data channels. > Please let us discuss NDATA issues on the tsvwg mailing list... >=20 > Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its = benefits outweigh its costs. The current draft does not pass that bar = for me. If my app cares about HOL blocking, NDATA is not very useful, so = my app must internally fragment, hence NDATA actually becomes harmful (8 = bytes closer to exceeding MTU, forcing SCTP fragments and hence risking = HOL blocking). I don't understand the point when I look at the API for data channels... = Only for sending messages on a data channel not requiring ordered delivery. However, the intention = of NDATA is to mitigate the impact of one data channel on others belonging to the same peer = connection. This goal is met. Best regards Michael >=20 > Best regards > Michael >>=20 >> Mo >>=20 >> PS. Some believe data channels will be more widely used than WebRTC = media (webtorrent, etc.), so it does make sense to consider the = desirable properties of a general peer-to-peer transport, and drop the = WebRTC prefix when talking about data channels. >=20 >=20 From nobody Wed Oct 29 05:10:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E859B1A0078 for ; Wed, 29 Oct 2014 05:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20-_bGiFHTL2 for ; Wed, 29 Oct 2014 05:09:55 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734221A0070 for ; Wed, 29 Oct 2014 05:09:55 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ex7so4371141wid.4 for ; Wed, 29 Oct 2014 05:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=/Awp2kR3z/qQBmj6os2avosdsr+MOqVJOoqXl/KiYgs=; b=ODRLQ7Ja/JTRZHVBntGebOHL8uNQRZOG/jWwg1nwLIYVteLgxkLzq9lWpgHTOu1RPD CmmqMnXnaCLbaSscOw+C5AUxxXkaL3aAVP5Go9q2DcGUL7gPfWZV6UEFmGSCP4aH5Rfn 3LUkWg8J3ZUSw684JfhslJVfbzhaWa6VLqnpwPWtmeKsLQN1ZCZ4dQvs1MNClWqVDsGm +EcxOnt1wc20Sq3aHh1XgOVrEO67Xa4dSlpUsRRZ5+ng7tVNhcspfZ+03jWs3ywYWu8j /A/DKMrhd1hngO96jtQO81C6vJapQ9CNUdxl/dC8SPuHw90vM+mICLQ6p4g2qVEe9Ci8 +5zg== X-Received: by 10.180.106.104 with SMTP id gt8mr20953004wib.51.1414584593981; Wed, 29 Oct 2014 05:09:53 -0700 (PDT) Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id q10sm4972154wjq.35.2014.10.29.05.09.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 05:09:53 -0700 (PDT) Message-ID: <5450D91D.9030507@gmail.com> Date: Wed, 29 Oct 2014 13:10:05 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com> <544936E5.2040909@mozilla.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090102050609030408020309" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FRXGlRlGKMWxnZiUw8JnWBwiZzY Subject: Re: [rtcweb] SDP and ssrc-group, X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 12:10:00 -0000 This is a multi-part message in MIME format. --------------090102050609030408020309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Indeed, that was my original concern also. Using the order of ssrc-ids on the ssrc-group may be the simplest way to solve it, but not sure if it would allow more complex FEC scenarios, like one FEC stream protecting two media flows (maybe not relevant at all). I have been surfing at the ietf rfcs, and found and interesting one rfc6364 which defines fec-source-flow and fec-repair-flow media attributes that can be used with a=group:FEC-FR, hat would allow exactly what we need: v=0 o=ali 1122334455 1122334466 IN IP4 fec.example.com s=FEC Framework Examples t=0 0 a=group:FEC-FR S1 R1 m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=rtpmap:100 MP2T/90000 a=fec-source-flow: id=0 a=mid:S1 m=application 30000 UDP/FEC c=IN IP4 233.252.0.2/127 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 a=repair-window:150ms a=mid:R1 We would need to port thatould neerc-group semantics, like for example m=video 30000 RTP/AVP 100 101 108 109 110 111 c=IN IP4 233.252.0.1 a=rtpmap:100 VP8/90000 a=rtpmap:101 VP9/90000 a=rtpmap:108 rtx/90000 a=rtpmap:109 rtx/90000 a=fmtp:108 apt=100 a=fmtp:109 apt=101 a=rtpmap:110 interleaved-parityfec/90000 a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000 a=rtpmap:111 non-interleaved-parityfec/90000 a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000 a=ssrc:1234 fec-source-flow: id=0 a=ssrc:2345 a=ssrc:3456 fec-repair-flow: encoding-id=0; a=ssrc:4567 fec-repair-flow: encoding-id=0; a=ssrc-group:FID 1234 2345 a=ssrc-group:FEC-FR 1234 3456 4567 Best regards Sergio On 29/10/2014 5:23, Justin Uberti wrote: > So it's not clear to me that a=ssrc:X fmtp:Y is actually legal, > without any fmtp parameters, or that it clearly indicates that only PT > Y is to be sent on that SSRC. As such, I consider this solution to be > wishful thinking. > > I think it would be easier if we defined FEC/FID semantics such that > the initial SSRC was to be used for the primary encoding, and any > subsequent SSRCs were used for the secondary/tertiary streams. (e.g. > RTX or FEC) > > e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC: > > m=video 30000 RTP/AVP 100 101 108 109 110 111 > c=IN IP4 233.252.0.1 > a=rtpmap:100 VP8/90000 > a=rtpmap:101 VP9/90000 > a=rtpmap:108 rtx/90000 > a=rtpmap:109 rtx/90000 > a=fmtp:108 apt=100 > a=fmtp:109 apt=101 > a=rtpmap:110 interleaved-parityfec/90000 > a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000 > a=rtpmap:111 non-interleaved-parityfec/90000 > a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000 > a=ssrc:1234 > a=ssrc:2345 > a=ssrc:3456 > a=ssrc:4567 > a=ssrc-group:FID 1234 2345 > a=ssrc-group:FEC-FR 1234 3456 4567 > > SSRC 1234 is the primary encoding (VP8 or VP9) > SSRC 2345 is RTX (either PT 108 or 109, as needed) > SSRC 3456 is FEC (either PT 110 or 111, depending on impl) > SSRC 4567 is FEC (either PT 110 or 111, depending on impl) > > > On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) > > wrote: > > > > > Makaraju, Maridi Raju (Raju) wrote: > > > OPUS does have a built-in FEC so no need for red+ulpfec. > > > > As discussed previously on this list [1] the built-in FEC only > covers > > the SILK layer. Existing codec-agnostic mechanisms were perfectly > > adequate for protecting CELT-mode packets, so we didn't invent > something > > new. > > > > [1] > https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html > [Raju] Thanks and appreciate the reference. > > _______________________________________________ > 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 --------------090102050609030408020309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Indeed, that was my original concern also.

Using the order of ssrc-ids on the ssrc-group may be the simplest way to solve it, but not sure if it would allow more complex FEC scenarios, like one FEC stream protecting two media flows (maybe not relevant at all).

I have been surfing at the ietf rfcs, and found and interesting one rfc6364 which defines  fec-source-flow and fec-repair-flow media attributes that can be used with a=group:FEC-FR, hat would allow exactly what we need:

        v=0
        o=ali 1122334455 1122334466 IN IP4 fec.example.com
        s=FEC Framework Examples
        t=0 0
        a=group:FEC-FR S1 R1
        m=video 30000 RTP/AVP 100
        c=IN IP4 233.252.0.1/127
        a=rtpmap:100 MP2T/90000
        a=fec-source-flow: id=0
        a=mid:S1
        m=application 30000 UDP/FEC
        c=IN IP4 233.252.0.2/127
        a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
        a=repair-window:150ms
        a=mid:R1

We would need to port thatould neerc-group semantics, like for example

      

        
     m=video 30000 RTP/AVP 100 101 108 109 110 111

        

        
     c=IN IP4 233.252.0.1

        
     a=rtpmap:100 VP8/90000

        
     a=rtpmap:101 VP9/90000

        

        
     a=rtpmap:108 rtx/90000

        
     a=rtpmap:109 rtx/90000

        

        
     a=fmtp:108 apt=100

        
     a=fmtp:109 apt=101

        

        
     a=rtpmap:110 interleaved-parityfec/90000

        
     a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000

        
     a=rtpmap:111 non-interleaved-parityfec/90000

        
     a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000

        
     a=ssrc:1234 fec-source-flow: id=0

        

        
     a=ssrc:2345

        
     a=ssrc:3456 fec-repair-flow: encoding-id=0;

        
     a=ssrc:4567 fec-repair-flow: encoding-id=0;

        
     a=ssrc-group:FID 1234 2345

        
     a=ssrc-group:FEC-FR 1234 3456 4567

      

      

      Best regards

      Sergio

      On 29/10/2014 5:23, Justin Uberti wrote:

    

    

      
So it's not clear to me that a=ssrc:X fmtp:Y is
        actually legal, without any fmtp parameters, or that it clearly
        indicates that only PT Y is to be sent on that SSRC. As such, I
        consider this solution to be wishful thinking.
        


        

        
I think it would be easier if we defined FEC/FID semantics
          such that the initial SSRC was to be used for the primary
          encoding, and any subsequent SSRCs were used for the
          secondary/tertiary streams. (e.g. RTX or FEC)

        


        

        
e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC:

        
  

        

        

          
     m=video 30000 RTP/AVP 100 101 108 109 110 111

          

          
     c=IN IP4 233.252.0.1

          
     a=rtpmap:100 VP8/90000

          
     a=rtpmap:101 VP9/90000

          

          
     a=rtpmap:108 rtx/90000

          
     a=rtpmap:109 rtx/90000

          

          
     a=fmtp:108 apt=100

          
     a=fmtp:109 apt=101

          

          
     a=rtpmap:110 interleaved-parityfec/90000

          
     a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000

          
     a=rtpmap:111 non-interleaved-parityfec/90000

          
     a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000

          
     a=ssrc:1234

          
     a=ssrc:2345

          
     a=ssrc:3456

          
     a=ssrc:4567

          
     a=ssrc-group:FID 1234 2345

          
     a=ssrc-group:FEC-FR 1234 3456 4567

        

        


        

        
SSRC 1234 is the primary encoding (VP8 or VP9)

        
SSRC 2345 is RTX (either PT 108 or 109, as needed)

        
SSRC 3456 is FEC (either PT 110 or 111, depending on impl)

        
SSRC 4567 is FEC (either PT 110 or 111, depending on impl)

        


        

      

      


        
On Thu, Oct 23, 2014 at 12:29 PM,
          Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>
          wrote:

          
>

              > Makaraju, Maridi Raju (Raju) wrote:

              > > OPUS does have a built-in FEC so no need for
              red+ulpfec.

              >

              > As discussed previously on this list [1] the built-in
              FEC only covers

              > the SILK layer. Existing codec-agnostic mechanisms
              were perfectly

              > adequate for protecting CELT-mode packets, so we
              didn't invent something

              > new.

              >

              > [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html

            [Raju] Thanks and appreciate the reference.

            

              


                _______________________________________________

                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


    

    

  


--------------090102050609030408020309--


From nobody Wed Oct 29 05:24:30 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050001A00B0 for ; Wed, 29 Oct 2014 05:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.709
X-Spam-Level: 
X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baBdHCjO7qBd for ; Wed, 29 Oct 2014 05:24:16 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759841A00A6 for ; Wed, 29 Oct 2014 05:24:16 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 9E285EA30DF6B; Wed, 29 Oct 2014 12:24:11 +0000 (GMT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9TCODex005631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 08:24:13 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 08:24:13 -0400
From: "Makaraju, Maridi Raju (Raju)" 
To: Christer Holmberg , Martin Thomson , Justin Uberti 
Thread-Topic: [rtcweb] SDP and ssrc-group,
Thread-Index: AQHP7ViUdeZEO6Q8ck+bZW3ftl2D4pw85NsDgAD8OICAAFA5gP//4SjAgAi2HQCAABB1AIAAGbkAgAAI9tA=
Date: Wed, 29 Oct 2014 12:24:13 +0000
Message-ID: 
References:      <5F93BF20-03B2-4D2D-BEFC-ED91250993BD@gmail.com> <54480864.4050106@gmail.com> <5448583B.5090109@mozilla.com>  <544936E5.2040909@mozilla.com>    <7594FB04B1934943A5C02806D1A2204B1D4D2633@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D2633@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.17]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5F963BUS70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/buAK4VLXApSHQK4vUvi_kaedo0c
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] SDP and ssrc-group,
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 12:24:23 -0000

--_000_E1FE4C082A89A246A11D7F32A95A17828E5F963BUS70UWXCHMBA02z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2l0aG91dCBjb21tZW50aW5nIG9uIHRoaXMgc3BlY2lmaWMgbWVjaGFuaXNtLCBpbiBnZW5lcmFs
IHdlIHNob3VsZCBOT1QgZGVmaW5lIHNvbHV0aW9ucyB3aGljaCBhc3N1bWUgYSBjZXJ0YWluIG9y
ZGVyIG9mIGF0dHJpYnV0ZXMgKGFzc29jaWF0ZWQgd2l0aCBhIGdpdmVuIG0tIGxpbmUsIG9yIG9u
IHNlc3Npb24gbGV2ZWwpIGV0Yy4NCg0KSSBoYXZlIHNlZW4gbm9kZXMsIHdoZXJlIHRoZSBvcmRl
ciBvZiBhdHRyaWJ1dGVzIGhhcyBjaGFuZ2VkIGJldHdlZW4gdGhlIGluY29taW5nLSBhbmQgb3V0
Z29pbmcgU0RQLCBkdWUgdG8gdGhlIHdheSB0aGUgcGFyc2VyIGluIHRoZSBub2RlIGlzIGltcGxl
bWVudGVkLg0KDQpJIGFsc28gZG9u4oCZdCB0aGluayB3ZSBzaG91bGQgY2hhbmdlIHRoZSBzZW1h
bnRpY3Mgb2YgdGhlIFBUIG9yZGVyIGluIHRoZSBtLSBsaW5lLg0KDQo8UmFqdT4NCg0KSSBhZ3Jl
ZSB3aXRoIHRoZSBhYm92ZSBjb21tZW50cy4gQUZBSUssIFNEUCBoYXMgc2Vzc2lvbiBsZXZlbCBh
bmQgbWVkaWEgbGV2ZWwgc2VtYW50aWNzLCBidXQgbm8gb3JkZXIgKG9mIGE9IGxpbmVzKSBiYXNl
ZCBzZW1hbnRpY3MuDQoNCkkgYWxzbyBhZ3JlZSB0aGF0IOKAnGE9c3NyYzo8c3NyYz4gZm10cDo8
Zm9ybWF0Iz7igJ0gZG9lcyBub3QgZ2l2ZSBhIGNsZWFyIGFuc3dlci4NCg0KSG93IGFib3V0IGV4
dGVuZGluZyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NTc2I3NlY3Rpb24tNi4zIHRv
IGFkZCBhIG5ldyDigJxmbXRwc+KAnSB0byBhc3NvY2lhdGUgYWxsb3dlZCBmb3JtYXRzIHRvIGFu
IHNzcmMgYW5kIGRlZmluZSBzZW1hbnRpY3MgdW5hbWJpZ3VvdXNseT8gSnVzdGlu4oCZcyBleGFt
cGxlIHdvdWxkIGJlY29tZSBsaWtlIHRoaXM6DQoNCg0KICAgICBtPXZpZGVvIDMwMDAwIFJUUC9B
VlAgMTAwIDEwMSAxMDggMTA5IDExMCAxMTENCiAgICAgYz1JTiBJUDQgMjMzLjI1Mi4wLjENCiAg
ICAgYT1ydHBtYXA6MTAwIFZQOC85MDAwMA0KICAgICBhPXJ0cG1hcDoxMDEgVlA5LzkwMDAwDQog
ICAgIGE9cnRwbWFwOjEwOCBydHgvOTAwMDANCiAgICAgYT1ydHBtYXA6MTA5IHJ0eC85MDAwMA0K
ICAgICBhPWZtdHA6MTA4IGFwdD0xMDANCiAgICAgYT1mbXRwOjEwOSBhcHQ9MTAxDQogICAgIGE9
cnRwbWFwOjExMCBpbnRlcmxlYXZlZC1wYXJpdHlmZWMvOTAwMDANCiAgICAgYT1mbXRwOjExMCBM
OjU7IEQ6MTA7IFRvUDoyOyByZXBhaXItd2luZG93OjIwMDAwMA0KICAgICBhPXJ0cG1hcDoxMTEg
bm9uLWludGVybGVhdmVkLXBhcml0eWZlYy85MDAwMA0KICAgICBhPWZtdHA6MTExIEw6NTsgRDox
MDsgVG9QOjI7IHJlcGFpci13aW5kb3c6MjAwMDAwDQogICAgIGE9c3NyYzoxMjM0IGZtdHBzOjEw
MCwxMDENCiAgICAgYT1zc3JjOjIzNDUgZm10cHM6MTA4LDEwOQ0KICAgICBhPXNzcmM6MzQ1NiBm
bXRwczoxMTAsMTExDQogICAgIGE9c3NyYzo0NTY3IGZtdHBzOjExMCwxMTENCiAgICAgYT1zc3Jj
LWdyb3VwOkZJRCAxMjM0IDIzNDUNCiAgICAgYT1zc3JjLWdyb3VwOkZFQy1GUiAxMjM0IDM0NTYg
NDU2Nw0KDQpUaGUgZm10cHMgbWFwcGluZ3MgZ2l2ZSB0aGUgZm9sbG93aW5nIGFzc29jaWF0aW9u
czoNClNTUkMgMTIzNCBpcyB0aGUgcHJpbWFyeSBlbmNvZGluZyAoVlA4IG9yIFZQOSkNClNTUkMg
MjM0NSBpcyBSVFggKGVpdGhlciBQVCAxMDggb3IgMTA5LCBhcyBuZWVkZWQpDQpTU1JDIDM0NTYg
aXMgRkVDIChlaXRoZXIgUFQgMTEwIG9yIDExMSwgZGVwZW5kaW5nIG9uIGltcGwpDQpTU1JDIDQ1
NjcgaXMgRkVDIChlaXRoZXIgUFQgMTEwIG9yIDExMSwgZGVwZW5kaW5nIG9uIGltcGwpDQoNCg0K
PC9SYWp1Pg0K

--_000_E1FE4C082A89A246A11D7F32A95A17828E5F963BUS70UWXCHMBA02z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg
MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2l0aG91dCBjb21tZW50aW5nIG9uIHRoaXMgc3BlY2lm
aWMgbWVjaGFuaXNtLCBpbiBnZW5lcmFsIHdlIHNob3VsZCBOT1QgZGVmaW5lIHNvbHV0aW9ucyB3
aGljaCBhc3N1bWUgYSBjZXJ0YWluIG9yZGVyIG9mIGF0dHJpYnV0ZXMgKGFzc29jaWF0ZWQgd2l0
aCBhIGdpdmVuIG0tIGxpbmUsIG9yIG9uIHNlc3Npb24NCiBsZXZlbCkgZXRjLiA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+SSBoYXZlIHNlZW4gbm9kZXMsIHdoZXJlIHRoZSBvcmRlciBvZiBhdHRyaWJ1dGVzIGhhcyBj
aGFuZ2VkIGJldHdlZW4gdGhlIGluY29taW5nLSBhbmQgb3V0Z29pbmcgU0RQLCBkdWUgdG8gdGhl
IHdheSB0aGUgcGFyc2VyIGluIHRoZSBub2RlIGlzIGltcGxlbWVudGVkLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J
IGFsc28gZG9u4oCZdCB0aGluayB3ZSBzaG91bGQgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgdGhl
IFBUIG9yZGVyIGluIHRoZSBtLSBsaW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl
PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtSYWp1Jmd0OzxvOnA+PC9vOnA+PC9zcGFu
PjwvaT48L2I+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0
Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3Jl
ZSB3aXRoIHRoZSBhYm92ZSBjb21tZW50cy4gQUZBSUssIFNEUCBoYXMgc2Vzc2lvbiBsZXZlbCBh
bmQgbWVkaWEgbGV2ZWwgc2VtYW50aWNzLCBidXQgbm8gb3JkZXIgKG9mIGE9IGxpbmVzKSBiYXNl
ZCBzZW1hbnRpY3MuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBzdHlsZT0ibWFy
Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFsc28gYWdyZWUgdGhhdCDigJxhPXNzcmM6Jmx0O3Nz
cmMmZ3Q7IGZtdHA6Jmx0O2Zvcm1hdCMmZ3Q74oCdIGRvZXMgbm90IGdpdmUgYSBjbGVhciBhbnN3
ZXIuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt
YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5Ib3cgYWJvdXQgZXh0ZW5kaW5nDQo8L3NwYW4+PC9pPjwvYj48Yj48aT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTU3NiNzZWN0aW9uLTYuMyI+aHR0cDovL3Rvb2xzLmll
dGYub3JnL2h0bWwvcmZjNTU3NiNzZWN0aW9uLTYuMzwvYT4gdG8gYWRkIGEgbmV3IOKAnGZtdHBz
4oCdIHRvIGFzc29jaWF0ZSBhbGxvd2VkIGZvcm1hdHMNCiB0byBhbiBzc3JjIGFuZCBkZWZpbmUg
c2VtYW50aWNzIHVuYW1iaWd1b3VzbHk/IEp1c3RpbuKAmXMgZXhhbXBsZSB3b3VsZCBiZWNvbWUg
bGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgc3R5bGU9Im1hcmdp
bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO209dmlkZW8gMzAwMDAg
UlRQL0FWUCAxMDAgMTAxIDEwOCAxMDkgMTEwIDExMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtjPUlOIElQNCAyMzMuMjUyLjAuMTxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXJ0
cG1hcDoxMDAgVlA4LzkwMDAwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsgJm5ic3A7ICZuYnNwO2E9cnRwbWFwOjEwMSBWUDkvOTAwMDA8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7YT1ydHBtYXA6MTA4IHJ0
eC85MDAwMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw
OyAmbmJzcDthPXJ0cG1hcDoxMDkgcnR4LzkwMDAwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2E9Zm10cDoxMDggYXB0PTEwMDxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPWZtdHA6
MTA5IGFwdD0xMDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm
bmJzcDsgJm5ic3A7YT1ydHBtYXA6MTEwIGludGVybGVhdmVkLXBhcml0eWZlYy85MDAwMDxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPWZt
dHA6MTEwIEw6NTsgRDoxMDsgVG9QOjI7IHJlcGFpci13aW5kb3c6MjAwMDAwPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2E9cnRwbWFwOjEx
MSBub24taW50ZXJsZWF2ZWQtcGFyaXR5ZmVjLzkwMDAwPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO2E9Zm10cDoxMTEgTDo1OyBEOjEwOyBU
b1A6MjsgcmVwYWlyLXdpbmRvdzoyMDAwMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7YT1zc3JjOjEyMzQgZm10cHM6MTAwLDEwMTxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXNz
cmM6MjM0NSBmbXRwczoxMDgsMTA5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDsgJm5ic3A7ICZuYnNwO2E9c3NyYzozNDU2IGZtdHBzOjExMCwxMTE8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7YT1zc3JjOjQ1
NjcgZm10cHM6MTEwLDExMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7ICZuYnNwOyAmbmJzcDthPXNzcmMtZ3JvdXA6RklEIDEyMzQgMjM0NTxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthPXNzcmMtZ3JvdXA6
RkVDLUZSIDEyMzQgMzQ1NiA0NTY3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmbXRwcyBt
YXBwaW5ncyBnaXZlIHRoZSBmb2xsb3dpbmcgYXNzb2NpYXRpb25zOjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+U1NSQyAxMjM0IGlzIHRoZSBwcmltYXJ5IGVuY29kaW5nIChW
UDggb3IgVlA5KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U1NSQyAyMzQ1
IGlzIFJUWCAoZWl0aGVyIFBUIDEwOCBvciAxMDksIGFzIG5lZWRlZCk8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNTUkMgMzQ1NiBpcyBGRUMgKGVpdGhlciBQVCAxMTAgb3Ig
MTExLCBkZXBlbmRpbmcgb24gaW1wbCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlNTUkMgNDU2NyBpcyBGRUMgKGVpdGhlciBQVCAxMTAgb3IgMTExLCBkZXBlbmRpbmcgb24g
aW1wbCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48
aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0Oy9SYWp1Jmd0
Ozwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_E1FE4C082A89A246A11D7F32A95A17828E5F963BUS70UWXCHMBA02z_--


From nobody Wed Oct 29 05:30:16 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B361A00A6 for ; Wed, 29 Oct 2014 05:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk_B6WxWV1o9 for ; Wed, 29 Oct 2014 05:30:13 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BEFD1A006F for ; Wed, 29 Oct 2014 05:30:13 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id q5so1528901wiv.16 for ; Wed, 29 Oct 2014 05:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XyXdJKAI8xp0Fe5/8ME8j3Z86Z3t1FXyWqxIUfIKYBU=; b=g9YbVTociynnyGRvlDx2mAiZY/KVoUw+R/c8KXCvmCFeFQDjUbUtM/Vbz+/2EnP4zT 1m42cgSuiUz4vdro5Y9qR//HIJG0UalJIDbCY9o7r9RxQGs/Q+Qjtn6zFEn5dWi2hNvh 4g/gpbB1w3mIOklGTmwgFpYz8RD0ST+8T8+3XxfZcbRVET3/wpnPsNdkMgzSuw2kBgc+ 5s08FNfz3bXFVsQNApWZDqswp9ag0uVmxvZOeDf07D+f5GUn5a8M5gL9A6y/1eMd+7vy E+hme7EP6iOb/HSNCT0BsVMZ2YlBNjCAcU3sz1SjbOAJh2IKLCCUKz1YKpHh5/xBsazL GJKA==
X-Received: by 10.180.9.33 with SMTP id w1mr11694564wia.22.1414585811762; Wed, 29 Oct 2014 05:30:11 -0700 (PDT)
Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id cz3sm5040556wjb.23.2014.10.29.05.30.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 05:30:10 -0700 (PDT)
Message-ID: <5450DDDE.5020802@gmail.com>
Date: Wed, 29 Oct 2014 13:30:22 +0100
From: Sergio Garcia Murillo 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <095701cff34c$ad1089c0$07319d40$@gmail.com>
In-Reply-To: <095701cff34c$ad1089c0$07319d40$@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-xnVbuRrwPz4hfE1DW1y2YZ0B8A
Subject: Re: [rtcweb] SDP and ssrc-group,
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 12:30:15 -0000

 From a formal perspective, I don't feel it is correct to describe the 
semantical meaning of an ssrc by referring to a payload.

Best regards
Sergio
On 29/10/2014 8:48, Roni Even wrote:
> Hi,
> We discussed this mapping issue in a previous version of the application token draft http://tools.ietf.org/html/draft-even-mmusic-application-token-02 example in section 1.
> We thought of having a mapping from appId to "pt" (section 3.3.1)
> Roni
>
>> -----Original Message-----
>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of I?aki Baz Castillo
>> Sent: 21 October, 2014 7:26 PM
>> To: rtcweb@ietf.org
>> Subject: [rtcweb] SDP and ssrc-group,
>>
>> Hi,
>>
>> May I know which SSRC (345259865 or 2693756249) will be used for the real
>> media stream (plus RED and FEC) and which SSRC will be used for RTX?
>>
>>
>>
>> --------------------------
>> m=video 62164 RTP/SAVPF 100 116 117 96
>> a=mid:video
>> a=rtpmap:100 VP8/90000
>> a=rtpmap:116 red/90000
>> a=rtpmap:117 ulpfec/90000
>> a=rtpmap:96 rtx/90000
>> a=fmtp:96 apt=100
>> a=ssrc-group:FID 345259865 2693756249
>> a=ssrc:345259865 cname:erS7E/KHLYKTejNs
>> a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>> c0134f05-e7c2-4afd-a979-4e224de5eb91
>> a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>> a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>> a=ssrc:2693756249 cname:erS7E/KHLYKTejNs
>> a=ssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>> c0134f05-e7c2-4afd-a979-4e224de5eb91
>> a=ssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>> a=ssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>> -------------------------------
>>
>>
>>
>>
>> RFC 5576 does not clarify it at all:
>>
>> http://tools.ietf.org/html/rfc5576#section-4.2
>>
>> --------------------------------------------------
>> 4.2.  The "ssrc-group" Media Attribute
>>
>>     a=ssrc-group:  ...
>>
>>     [..]
>>
>>     The  parameter is taken from the specification of the
>>     "group" attribute [RFC3388].  The initial semantic values defined for
>>     the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
>>     and FEC (Forward Error Correction) [RFC4756].  In each case, the
>>     relationship among the grouped sources is the same as the
>>     relationship among corresponding sources in media streams grouped
>>     using the SDP "group" attribute.
>> --------------------------------------------------
>>
>>
>>
>> The referenced RFC 3388 neither clarifies it:
>>
>> ---------------------------------------------------
>> 7.4 FID Semantics
>>
>>     Several "m" lines grouped together using FID semantics form a media
>>     flow.  A media agent handling a media flow that comprises several "m"
>>     lines MUST send a copy of the media to every "m" line part of the
>>     flow as long as the codecs and the direction attribute present in a
>>     particular "m" line allow it.
>>
>>     It is assumed that the application uses only one codec at a time to
>>     encode the media produced.  This codec MAY change dynamically during
>>     the session, but at any particular moment only one codec is in use.
>>
>>     The application encodes the media using the current codec and checks
>>     one by one all the "m" lines that are part of the flow.  If a
>>     particular "m" line contains the codec being used and the direction
>>     attribute is "sendonly" or "sendrecv", a copy of the encoded media is
>>     sent to the address/port specified in that particular media stream.
>>     If either the "m" line does not contain the codec being used or the
>>     direction attribute is neither "sendonly" nor "sendrecv", nothing is
>>     sent over this media stream.
>> ----------------------------------------------------
>>
>>
>>
>>
>> So, how is the usage of ssrc-group? Where is it really defined?
>>
>> Can I put more than 2 ssrc together in the same ssrc-group line?
>>
>> How should the receiver interpret it?
>>
>> Does a ssrc-group always mean RTX usage? Where is that specified in the
>> above SDP?
>>
>> Does not the above SDP look a complete mixture of hacks and workarounds?
>>
>>
>>
>>
>> --
>> Iñaki Baz Castillo
>> 
>>
>> _______________________________________________
>> 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 nobody Wed Oct 29 08:14:30 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6941A0439 for ; Wed, 29 Oct 2014 08:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0va42VfuWkpl for ; Wed, 29 Oct 2014 08:14:24 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABFD1A049A for ; Wed, 29 Oct 2014 08:14:17 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id n3so1992182wiv.0 for ; Wed, 29 Oct 2014 08:14:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=ZJFeUqquq1G1w60aAbeGG5yiRLUtV2jbBnzQO/d/F2o=; b=nOnq226X1MdTS47kuz9DJfyVCT8fsup+Qfv7kbUCU0LHGfYB/V5FQQ3vLKRV1aSUkA 5a0r74vveMSeDslKNIk/pxIH12lXWSsiqvnjqyKkngTe+Iep4ZNqsPvWYk/vi9SBY7w3 0nxgmllq6xd+fucuQ1kBXkEFFpQEVI5uZIHLIOncrEE3h5ZwhdS2WNxrxHCLofzWvg6g w6YpbABbDHPK52yB7aeqe/aRaBI0X6q5bIiAth0iqUh+znvhinhXMZmlU+TzzD5MynQ4 ZSqtWnvEDVM1q2f1Q949Oj1rPJaq8bXqE5Cb+Xu1cBfW7HYhWcI3a/o5WQdUp4TemYiB fFYw==
X-Received: by 10.194.82.104 with SMTP id h8mr13369418wjy.44.1414595655755; Wed, 29 Oct 2014 08:14:15 -0700 (PDT)
Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id fr6sm5860297wic.1.2014.10.29.08.14.14 for  (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Oct 2014 08:14:14 -0700 (PDT)
From: "Roni Even" 
To: "'Sergio Garcia Murillo'" , 
References:  <095701cff34c$ad1089c0$07319d40$@gmail.com> <5450DDDE.5020802@gmail.com>
In-Reply-To: <5450DDDE.5020802@gmail.com>
Date: Wed, 29 Oct 2014 17:14:11 +0200
Message-ID: <09a801cff38a$ffb28640$ff1792c0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIdm2glshlU301gGbh4Wgrmbmu/awLmGMkxAjjC642bguTR0A==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zbY7EssOnVVvFRT6nhcqOcqD84s
Subject: Re: [rtcweb] SDP and ssrc-group,
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 15:14:26 -0000

Hi,
In the application token proposal we were trying to address two FEC =
issues:

1. You assume that the SDP layer will know the SSRCs of the streams when =
making an offer. This may be true for point to point call but there are =
topologies =
(https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-04)=
 where the SSRCs may not be known to a Mixer who projects incoming RTP =
streams as is. This was the reason for the application token. (this is a =
general issue with other use cases when using SSRC in SDP and bundle =
tried to address part of it for identifying the received RTP streams =
using the SDP group mid values)

2. For this case instead of using ssrc-group we proposed appId-group and =
define the mapping between an appId and the pt number to help identify =
the relation in the SDP between the FEC streams and the source streams.


We had the feeling that the using the SSRC in SDP was causing multiple =
issues and by using a token that does not have an RTP layer semantics we =
can have a cleaner solution.


Roni

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio =
Garcia
> Murillo
> Sent: 29 October, 2014 2:30 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] SDP and ssrc-group,
>=20
>  From a formal perspective, I don't feel it is correct to describe the =
semantical
> meaning of an ssrc by referring to a payload.
>=20
> Best regards
> Sergio
> On 29/10/2014 8:48, Roni Even wrote:
> > Hi,
> > We discussed this mapping issue in a previous version of the =
application token
> draft =
http://tools.ietf.org/html/draft-even-mmusic-application-token-02
> example in section 1.
> > We thought of having a mapping from appId to "pt" (section 3.3.1) =
Roni
> >
> >> -----Original Message-----
> >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of I?aki =
Baz
> >> Castillo
> >> Sent: 21 October, 2014 7:26 PM
> >> To: rtcweb@ietf.org
> >> Subject: [rtcweb] SDP and ssrc-group,
> >>
> >> Hi,
> >>
> >> May I know which SSRC (345259865 or 2693756249) will be used for =
the
> >> real media stream (plus RED and FEC) and which SSRC will be used =
for RTX?
> >>
> >>
> >>
> >> --------------------------
> >> m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 a=3Dmid:video
> >> a=3Drtpmap:100 VP8/90000
> >> a=3Drtpmap:116 red/90000
> >> a=3Drtpmap:117 ulpfec/90000
> >> a=3Drtpmap:96 rtx/90000
> >> a=3Dfmtp:96 apt=3D100
> >> a=3Dssrc-group:FID 345259865 2693756249
> >> a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs
> >> a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> >> c0134f05-e7c2-4afd-a979-4e224de5eb91
> >> a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> >> a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
> >> a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs
> >> a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> >> c0134f05-e7c2-4afd-a979-4e224de5eb91
> >> a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
> >> a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
> >> -------------------------------
> >>
> >>
> >>
> >>
> >> RFC 5576 does not clarify it at all:
> >>
> >> http://tools.ietf.org/html/rfc5576#section-4.2
> >>
> >> --------------------------------------------------
> >> 4.2.  The "ssrc-group" Media Attribute
> >>
> >>     a=3Dssrc-group:  ...
> >>
> >>     [..]
> >>
> >>     The  parameter is taken from the specification of =
the
> >>     "group" attribute [RFC3388].  The initial semantic values =
defined for
> >>     the "ssrc-group" attribute are FID (Flow Identification) =
[RFC3388]
> >>     and FEC (Forward Error Correction) [RFC4756].  In each case, =
the
> >>     relationship among the grouped sources is the same as the
> >>     relationship among corresponding sources in media streams =
grouped
> >>     using the SDP "group" attribute.
> >> --------------------------------------------------
> >>
> >>
> >>
> >> The referenced RFC 3388 neither clarifies it:
> >>
> >> ---------------------------------------------------
> >> 7.4 FID Semantics
> >>
> >>     Several "m" lines grouped together using FID semantics form a =
media
> >>     flow.  A media agent handling a media flow that comprises =
several "m"
> >>     lines MUST send a copy of the media to every "m" line part of =
the
> >>     flow as long as the codecs and the direction attribute present =
in a
> >>     particular "m" line allow it.
> >>
> >>     It is assumed that the application uses only one codec at a =
time to
> >>     encode the media produced.  This codec MAY change dynamically =
during
> >>     the session, but at any particular moment only one codec is in =
use.
> >>
> >>     The application encodes the media using the current codec and =
checks
> >>     one by one all the "m" lines that are part of the flow.  If a
> >>     particular "m" line contains the codec being used and the =
direction
> >>     attribute is "sendonly" or "sendrecv", a copy of the encoded =
media is
> >>     sent to the address/port specified in that particular media =
stream.
> >>     If either the "m" line does not contain the codec being used or =
the
> >>     direction attribute is neither "sendonly" nor "sendrecv", =
nothing is
> >>     sent over this media stream.
> >> ----------------------------------------------------
> >>
> >>
> >>
> >>
> >> So, how is the usage of ssrc-group? Where is it really defined?
> >>
> >> Can I put more than 2 ssrc together in the same ssrc-group line?
> >>
> >> How should the receiver interpret it?
> >>
> >> Does a ssrc-group always mean RTX usage? Where is that specified in =
the
> >> above SDP?
> >>
> >> Does not the above SDP look a complete mixture of hacks and =
workarounds?
> >>
> >>
> >>
> >>
> >> --
> >> I=C3=B1aki Baz Castillo
> >> 
> >>
> >> _______________________________________________
> >> 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 nobody Wed Oct 29 08:21:49 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9431A01D5 for ; Wed, 29 Oct 2014 08:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzP_sM0d2apE for ; Wed, 29 Oct 2014 08:21:34 -0700 (PDT)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F03C1A0636 for ; Wed, 29 Oct 2014 08:21:34 -0700 (PDT)
Received: by mail-wg0-f54.google.com with SMTP id m15so2144066wgh.13 for ; Wed, 29 Oct 2014 08:21:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3dbmsjcuhU+aPZV1Pw2nIhFq9BVIXSmNw9/DTQqUQuk=; b=nTn0bHLVE0KgtolSj0JOKNWniHoE5p9YPV9Mndpb7cgBpzCd/tgheiUh99/wK9rGJV V8lukKD/Vnc2wM6vyrFyLJ/Xmqo4bz2RAGsKXqZK1rClj4ZUsZbPI7sj3dw/jW6gSibJ V5zTz6JWQ5b0lAiqM3Jbota/v2/KenAia4QBy2MWw2sXwOnKMhdNRkvS+2Uz5rZmDgrV WOUbad5U3gM1fOI5+QjocgpYZzdlBsp3woPoTsolkkDpVmJUPFkBAEwLNy37cEtiYi7y 10OuN6ZZjUaq/5ZV4113bvwIvNHsksCwTATp7gEddk3Yll/IivchJB9RtYoym1wyV83Z YFfg==
X-Received: by 10.194.103.230 with SMTP id fz6mr13241885wjb.53.1414596093034;  Wed, 29 Oct 2014 08:21:33 -0700 (PDT)
Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id l5sm5877771wif.3.2014.10.29.08.21.31 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 08:21:32 -0700 (PDT)
Message-ID: <54510608.1030301@gmail.com>
Date: Wed, 29 Oct 2014 16:21:44 +0100
From: Sergio Garcia Murillo 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Roni Even , rtcweb@ietf.org
References:  <095701cff34c$ad1089c0$07319d40$@gmail.com> <5450DDDE.5020802@gmail.com> <09a801cff38a$ffb28640$ff1792c0$@gmail.com>
In-Reply-To: <09a801cff38a$ffb28640$ff1792c0$@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Mdd3RiKAa7s3kX5fOUCKtRFoqE4
Subject: Re: [rtcweb] SDP and ssrc-group,
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 15:21:38 -0000

Hi Roni,

I agree that knowing ssrcs in the SDP is a burden, but it is not only 
related to FEC/RTX. IMHO that should be handled in Plan A/B/C/whatever 
discussions which I have to confess that have not been actively following.

Best regards
Sergio
On 29/10/2014 16:14, Roni Even wrote:
> Hi,
> In the application token proposal we were trying to address two FEC issues:
>
> 1. You assume that the SDP layer will know the SSRCs of the streams when making an offer. This may be true for point to point call but there are topologies (https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-04) where the SSRCs may not be known to a Mixer who projects incoming RTP streams as is. This was the reason for the application token. (this is a general issue with other use cases when using SSRC in SDP and bundle tried to address part of it for identifying the received RTP streams using the SDP group mid values)
>
> 2. For this case instead of using ssrc-group we proposed appId-group and define the mapping between an appId and the pt number to help identify the relation in the SDP between the FEC streams and the source streams.
>
>
> We had the feeling that the using the SSRC in SDP was causing multiple issues and by using a token that does not have an RTP layer semantics we can have a cleaner solution.
>
>
> Roni
>
>> -----Original Message-----
>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia
>> Murillo
>> Sent: 29 October, 2014 2:30 PM
>> To: rtcweb@ietf.org
>> Subject: Re: [rtcweb] SDP and ssrc-group,
>>
>>   From a formal perspective, I don't feel it is correct to describe the semantical
>> meaning of an ssrc by referring to a payload.
>>
>> Best regards
>> Sergio
>> On 29/10/2014 8:48, Roni Even wrote:
>>> Hi,
>>> We discussed this mapping issue in a previous version of the application token
>> draft http://tools.ietf.org/html/draft-even-mmusic-application-token-02
>> example in section 1.
>>> We thought of having a mapping from appId to "pt" (section 3.3.1) Roni
>>>
>>>> -----Original Message-----
>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of I?aki Baz
>>>> Castillo
>>>> Sent: 21 October, 2014 7:26 PM
>>>> To: rtcweb@ietf.org
>>>> Subject: [rtcweb] SDP and ssrc-group,
>>>>
>>>> Hi,
>>>>
>>>> May I know which SSRC (345259865 or 2693756249) will be used for the
>>>> real media stream (plus RED and FEC) and which SSRC will be used for RTX?
>>>>
>>>>
>>>>
>>>> --------------------------
>>>> m=video 62164 RTP/SAVPF 100 116 117 96 a=mid:video
>>>> a=rtpmap:100 VP8/90000
>>>> a=rtpmap:116 red/90000
>>>> a=rtpmap:117 ulpfec/90000
>>>> a=rtpmap:96 rtx/90000
>>>> a=fmtp:96 apt=100
>>>> a=ssrc-group:FID 345259865 2693756249
>>>> a=ssrc:345259865 cname:erS7E/KHLYKTejNs
>>>> a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91
>>>> a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>>> a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>>>> a=ssrc:2693756249 cname:erS7E/KHLYKTejNs
>>>> a=ssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91
>>>> a=ssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>>> a=ssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>>>> -------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> RFC 5576 does not clarify it at all:
>>>>
>>>> http://tools.ietf.org/html/rfc5576#section-4.2
>>>>
>>>> --------------------------------------------------
>>>> 4.2.  The "ssrc-group" Media Attribute
>>>>
>>>>      a=ssrc-group:  ...
>>>>
>>>>      [..]
>>>>
>>>>      The  parameter is taken from the specification of the
>>>>      "group" attribute [RFC3388].  The initial semantic values defined for
>>>>      the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
>>>>      and FEC (Forward Error Correction) [RFC4756].  In each case, the
>>>>      relationship among the grouped sources is the same as the
>>>>      relationship among corresponding sources in media streams grouped
>>>>      using the SDP "group" attribute.
>>>> --------------------------------------------------
>>>>
>>>>
>>>>
>>>> The referenced RFC 3388 neither clarifies it:
>>>>
>>>> ---------------------------------------------------
>>>> 7.4 FID Semantics
>>>>
>>>>      Several "m" lines grouped together using FID semantics form a media
>>>>      flow.  A media agent handling a media flow that comprises several "m"
>>>>      lines MUST send a copy of the media to every "m" line part of the
>>>>      flow as long as the codecs and the direction attribute present in a
>>>>      particular "m" line allow it.
>>>>
>>>>      It is assumed that the application uses only one codec at a time to
>>>>      encode the media produced.  This codec MAY change dynamically during
>>>>      the session, but at any particular moment only one codec is in use.
>>>>
>>>>      The application encodes the media using the current codec and checks
>>>>      one by one all the "m" lines that are part of the flow.  If a
>>>>      particular "m" line contains the codec being used and the direction
>>>>      attribute is "sendonly" or "sendrecv", a copy of the encoded media is
>>>>      sent to the address/port specified in that particular media stream.
>>>>      If either the "m" line does not contain the codec being used or the
>>>>      direction attribute is neither "sendonly" nor "sendrecv", nothing is
>>>>      sent over this media stream.
>>>> ----------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> So, how is the usage of ssrc-group? Where is it really defined?
>>>>
>>>> Can I put more than 2 ssrc together in the same ssrc-group line?
>>>>
>>>> How should the receiver interpret it?
>>>>
>>>> Does a ssrc-group always mean RTX usage? Where is that specified in the
>>>> above SDP?
>>>>
>>>> Does not the above SDP look a complete mixture of hacks and workarounds?
>>>>
>>>>
>>>>
>>>>
>>>> -


From nobody Wed Oct 29 09:19:51 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6AE1A1ADE for ; Wed, 29 Oct 2014 09:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7VtiqoQ0fGb for ; Wed, 29 Oct 2014 09:19:45 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 08EC41A1ADF for ; Wed, 29 Oct 2014 09:19:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DEC447C4E94 for ; Wed, 29 Oct 2014 17:19:43 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJPgYZzVd961 for ; Wed, 29 Oct 2014 17:19:33 +0100 (CET)
Received: from [172.20.47.18] (50-200-68-226-static.hfc.comcastbusiness.net [50.200.68.226]) by mork.alvestrand.no (Postfix) with ESMTPSA id 516027C3CC7 for ; Wed, 29 Oct 2014 17:19:33 +0100 (CET)
Message-ID: <5451138E.9080507@alvestrand.no>
Date: Wed, 29 Oct 2014 09:19:26 -0700
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <0683D6CB32AC424D8AF52C0F660E5DC564ECB5EA@xmb-aln-x10.cisco.com>
In-Reply-To: <0683D6CB32AC424D8AF52C0F660E5DC564ECB5EA@xmb-aln-x10.cisco.com>
Content-Type: multipart/alternative; boundary="------------080603020600030202030404"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2L5JvFg8HUB99VV25SbMyWb-w0E
Subject: Re: [rtcweb] Notification for draft-benham-rtcweb-vp8litigation-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 16:19:47 -0000

This is a multi-part message in MIME format.
--------------080603020600030202030404
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Nice to have this information available.


The Duane Morris report is missing information about a couple of
on-going invalidity actions. We've sent information to the I-D editors.
Hopefully, they will update the document to be more complete.


-- 
Surveillance is pervasive. Go Dark.


--------------080603020600030202030404
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    

      
      
Nice
        to have this information available.

      

      The Duane Morris report is missing information about a couple of
      on-going invalidity actions. We've sent information to the I-D
      editors. Hopefully, they will update the document to be more
      complete.
      
      

      

    

    

    
-- 
Surveillance is pervasive. Go Dark.


  


--------------080603020600030202030404--


From nobody Wed Oct 29 10:20:51 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48B11A6F6B for ; Wed, 29 Oct 2014 10:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZANI9zmCLqM for ; Wed, 29 Oct 2014 10:20:44 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35701A6F57 for ; Wed, 29 Oct 2014 10:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=431; q=dns/txt; s=iport; t=1414603244; x=1415812844; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Bb6RvhXIIaVsYyiJdYbXF8lPHLK5d6Sh/shxkMEnZ18=; b=A2guJkzZyPpLkaRQrhwOa63J8vfBTvBehY/6yxGmCrs5LZ5pd5xJEsnN Ag+C82riAiS0kZPxKt/47pmXGIb2U6gmtDE1H7sM2phVB7mdqSAy95HYW jZF4WCGMOZZNI1O/BA4wqUoKp8zsai8kuFTjp/DmUKnRxIQztbqZt/InC Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAJ4gUVStJA2H/2dsb2JhbABcgw6BMNVuAoEbFgEBAQEBfYQDAQEDATo9Bw0BCCIUQiYBBAEaiDAIAcd+AQEBAQEFAQEBAQEBHJBdAoNlgR4BBJINjQ6NZIcrg3iCNIEDAQEB
X-IronPort-AV: E=Sophos;i="5.07,278,1413244800"; d="scan'208";a="367560465"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2014 17:20:44 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9THKhZ8022849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 17:20:44 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.253]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 12:20:43 -0500
From: "David Benham (dbenham)" 
To: "Harald Alvestrand (harald@alvestrand.no)" , "rtcweb@ietf.org" 
Thread-Topic: Re: [rtcweb] Notification for draft-benham-rtcweb-vp8litigation-00.txt
Thread-Index: Ac/znKfMgaVu97f3R2ixscsEjdyYbA==
Date: Wed, 29 Oct 2014 17:20:42 +0000
Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC564ECD7F4@xmb-aln-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [171.68.20.97]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/G2s47HXcXfLPEdZB_BYIBq-bRm0
Subject: Re: [rtcweb] Notification for draft-benham-rtcweb-vp8litigation-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 17:20:48 -0000

We'll be having those looked in to and report/draft subsequently updated.

> Nice to have this information available.
>
>The Duane Morris report is missing information about a couple of on-going =
invalidity actions.  We've=20
>sent information to the I-D editors. Hopefully, they will update the docum=
ent to be more complete.

P.S.    Terriberry, will use a different acronym, RFRAND, in any subsequent=
 I-D update.


From nobody Wed Oct 29 12:34:59 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE861A89AE for ; Wed, 29 Oct 2014 12:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.788
X-Spam-Level: 
X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaQ8vLLILb9R for ; Wed, 29 Oct 2014 12:34:54 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F0A1A89A8 for ; Wed, 29 Oct 2014 12:34:54 -0700 (PDT)
Received: by mail-oi0-f52.google.com with SMTP id u20so2836891oif.39 for ; Wed, 29 Oct 2014 12:34:54 -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; bh=Ek3OlInYZotzAMGD6C1omNyKKM3+z654RKSVlKjtDRM=; b=eY5MrW436U0ETVEZUKoLGFBGmCLBURfikg2dDEoJbM4DEV/kOk/1YRsZNriDg25cMI iv8A7kCb3dr10WVT2nfbpQ9j/odEBzgQw54GqyuD48YpYd2CkAYhdZ+S+w2zC8g/9USc gJLoSesgIrruITzRjXt8aVg9usp0xgmbKh7nKPX8EI5lfa4QJ68UTbFhZ6htwuCu0JBx s9d6VrlZRZWFZwGosOasBzmzQCqvqgmYymjJ+1819lGFOJW17bNDeLF85Gred5rXYbUZ GKItM0QSaeGpuCipJL9ZQXlMJesKzysQ+W6c8AQ8TyMGhhj0ttYhsIjPRMop9NK3DId1 i92g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ek3OlInYZotzAMGD6C1omNyKKM3+z654RKSVlKjtDRM=; b=Y31xfvGUd+SXRC6AWvCwF/KPP5n5jsXIJ9KDeRDnc3u4kHCx4g/kNsEECdYQMWb0ys wuKOBzOP9Tbr9Sh5nNDcQNdp40xrCnmXCwSIFGPXU7U8XG0Lczm73DYvbRjYYROCPOmC 5S9B8WRKXFn61E+L0Kjy+1kXdI83COLJ0cmHBfH3SfXOTTOYk9tuOgmVEDQSqOBQgFfl RoMPiKpvFFfym2DjAHcP6nAiVo8CdY2YguMyFK5yfusJtTXILke1vfi5yyCbuwAgY2Qw qpUIrCujPhBcWUdDvc+0nQfQHygfA/yayxMUhtNumJQHUs7wUBWQGxZpyMqJP2mC3lMN PrbQ==
X-Gm-Message-State: ALoCoQn+DwPbi0+s2TYLVWficSm2vmwmf2/OyeuTE6YDMhlb+ys+7vCDd4VE1i6gW0VxALijBRPB
X-Received: by 10.60.57.41 with SMTP id f9mr10183986oeq.17.1414611293859; Wed, 29 Oct 2014 12:34:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.248.170 with HTTP; Wed, 29 Oct 2014 12:34:33 -0700 (PDT)
In-Reply-To: <54510608.1030301@gmail.com>
References:  <095701cff34c$ad1089c0$07319d40$@gmail.com> <5450DDDE.5020802@gmail.com> <09a801cff38a$ffb28640$ff1792c0$@gmail.com> <54510608.1030301@gmail.com>
From: Justin Uberti 
Date: Wed, 29 Oct 2014 12:34:33 -0700
Message-ID: 
To: Sergio Garcia Murillo 
Content-Type: multipart/alternative; boundary=089e015389eeaaa3ae050694dbb6
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_tRQsAiqLXugxctWSJ6F8oFnUdM
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] SDP and ssrc-group,
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 19:34:57 -0000

--089e015389eeaaa3ae050694dbb6
Content-Type: text/plain; charset=UTF-8

Correlation of RTP flow to m= line is being done by the mid header
extension. Correlation of an individual RTP flow to its 'role' (e.g. FEC,
RTX) within a m= line can be inferred from received data (e.g. either FEC
or RTX), or determined explicitly from a=ssrc-group attributes, perhaps
with the addition of some additional meta-information.

To be absolutely clear, I was trying to suggest that the first SSRC in an
a=ssrc-group line should indicate the primary stream, and subsequent ones
the secondary streams (e.g. FID/FEC). I was not trying to suggest any other
ordering within the SDP has any bearing on this question.

On Wed, Oct 29, 2014 at 8:21 AM, Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> Hi Roni,
>
> I agree that knowing ssrcs in the SDP is a burden, but it is not only
> related to FEC/RTX. IMHO that should be handled in Plan A/B/C/whatever
> discussions which I have to confess that have not been actively following.
>
> Best regards
> Sergio
>
> On 29/10/2014 16:14, Roni Even wrote:
>
>> Hi,
>> In the application token proposal we were trying to address two FEC
>> issues:
>>
>> 1. You assume that the SDP layer will know the SSRCs of the streams when
>> making an offer. This may be true for point to point call but there are
>> topologies (https://tools.ietf.org/html/draft-ietf-avtcore-rtp-
>> topologies-update-04) where the SSRCs may not be known to a Mixer who
>> projects incoming RTP streams as is. This was the reason for the
>> application token. (this is a general issue with other use cases when using
>> SSRC in SDP and bundle tried to address part of it for identifying the
>> received RTP streams using the SDP group mid values)
>>
>> 2. For this case instead of using ssrc-group we proposed appId-group and
>> define the mapping between an appId and the pt number to help identify the
>> relation in the SDP between the FEC streams and the source streams.
>>
>>
>> We had the feeling that the using the SSRC in SDP was causing multiple
>> issues and by using a token that does not have an RTP layer semantics we
>> can have a cleaner solution.
>>
>>
>> Roni
>>
>>  -----Original Message-----
>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia
>>> Murillo
>>> Sent: 29 October, 2014 2:30 PM
>>> To: rtcweb@ietf.org
>>> Subject: Re: [rtcweb] SDP and ssrc-group,
>>>
>>>   From a formal perspective, I don't feel it is correct to describe the
>>> semantical
>>> meaning of an ssrc by referring to a payload.
>>>
>>> Best regards
>>> Sergio
>>> On 29/10/2014 8:48, Roni Even wrote:
>>>
>>>> Hi,
>>>> We discussed this mapping issue in a previous version of the
>>>> application token
>>>>
>>> draft http://tools.ietf.org/html/draft-even-mmusic-application-token-02
>>> example in section 1.
>>>
>>>> We thought of having a mapping from appId to "pt" (section 3.3.1) Roni
>>>>
>>>>  -----Original Message-----
>>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of I?aki Baz
>>>>> Castillo
>>>>> Sent: 21 October, 2014 7:26 PM
>>>>> To: rtcweb@ietf.org
>>>>> Subject: [rtcweb] SDP and ssrc-group,
>>>>>
>>>>> Hi,
>>>>>
>>>>> May I know which SSRC (345259865 or 2693756249) will be used for the
>>>>> real media stream (plus RED and FEC) and which SSRC will be used for
>>>>> RTX?
>>>>>
>>>>>
>>>>>
>>>>> --------------------------
>>>>> m=video 62164 RTP/SAVPF 100 116 117 96 a=mid:video
>>>>> a=rtpmap:100 VP8/90000
>>>>> a=rtpmap:116 red/90000
>>>>> a=rtpmap:117 ulpfec/90000
>>>>> a=rtpmap:96 rtx/90000
>>>>> a=fmtp:96 apt=100
>>>>> a=ssrc-group:FID 345259865 2693756249
>>>>> a=ssrc:345259865 cname:erS7E/KHLYKTejNs
>>>>> a=ssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91
>>>>> a=ssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>>>> a=ssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>>>>> a=ssrc:2693756249 cname:erS7E/KHLYKTejNs
>>>>> a=ssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>>>> c0134f05-e7c2-4afd-a979-4e224de5eb91
>>>>> a=ssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
>>>>> a=ssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91
>>>>> -------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> RFC 5576 does not clarify it at all:
>>>>>
>>>>> http://tools.ietf.org/html/rfc5576#section-4.2
>>>>>
>>>>> --------------------------------------------------
>>>>> 4.2.  The "ssrc-group" Media Attribute
>>>>>
>>>>>      a=ssrc-group:  ...
>>>>>
>>>>>      [..]
>>>>>
>>>>>      The  parameter is taken from the specification of the
>>>>>      "group" attribute [RFC3388].  The initial semantic values defined
>>>>> for
>>>>>      the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
>>>>>      and FEC (Forward Error Correction) [RFC4756].  In each case, the
>>>>>      relationship among the grouped sources is the same as the
>>>>>      relationship among corresponding sources in media streams grouped
>>>>>      using the SDP "group" attribute.
>>>>> --------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> The referenced RFC 3388 neither clarifies it:
>>>>>
>>>>> ---------------------------------------------------
>>>>> 7.4 FID Semantics
>>>>>
>>>>>      Several "m" lines grouped together using FID semantics form a
>>>>> media
>>>>>      flow.  A media agent handling a media flow that comprises several
>>>>> "m"
>>>>>      lines MUST send a copy of the media to every "m" line part of the
>>>>>      flow as long as the codecs and the direction attribute present in
>>>>> a
>>>>>      particular "m" line allow it.
>>>>>
>>>>>      It is assumed that the application uses only one codec at a time
>>>>> to
>>>>>      encode the media produced.  This codec MAY change dynamically
>>>>> during
>>>>>      the session, but at any particular moment only one codec is in
>>>>> use.
>>>>>
>>>>>      The application encodes the media using the current codec and
>>>>> checks
>>>>>      one by one all the "m" lines that are part of the flow.  If a
>>>>>      particular "m" line contains the codec being used and the
>>>>> direction
>>>>>      attribute is "sendonly" or "sendrecv", a copy of the encoded
>>>>> media is
>>>>>      sent to the address/port specified in that particular media
>>>>> stream.
>>>>>      If either the "m" line does not contain the codec being used or
>>>>> the
>>>>>      direction attribute is neither "sendonly" nor "sendrecv", nothing
>>>>> is
>>>>>      sent over this media stream.
>>>>> ----------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> So, how is the usage of ssrc-group? Where is it really defined?
>>>>>
>>>>> Can I put more than 2 ssrc together in the same ssrc-group line?
>>>>>
>>>>> How should the receiver interpret it?
>>>>>
>>>>> Does a ssrc-group always mean RTX usage? Where is that specified in the
>>>>> above SDP?
>>>>>
>>>>> Does not the above SDP look a complete mixture of hacks and
>>>>> workarounds?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -
>>>>>
>>>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--089e015389eeaaa3ae050694dbb6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Correlation of RTP flow to m=3D line is being done by the =
mid header extension. Correlation of an individual RTP flow to its 'rol=
e' (e.g. FEC, RTX) within a m=3D line can be inferred from received dat=
a (e.g. either FEC or RTX), or determined explicitly from a=3Dssrc-group at=
tributes, perhaps with the addition of some additional meta-information.
To be absolutely clear, I was trying to suggest that the f=
irst SSRC in an a=3Dssrc-group line should indicate the primary stream, and=
 subsequent ones the secondary streams (e.g. FID/FEC). I was not trying to =
suggest any other ordering within the SDP has any bearing on this question.=


On We=
d, Oct 29, 2014 at 8:21 AM, Sergio Garcia Murillo <sergio.ga=
rcia.murillo@gmail.com> wrote:
Hi Roni,



I agree that knowing ssrcs in the SDP is a burden, but it is not only relat=
ed to FEC/RTX. IMHO that should be handled in Plan A/B/C/whatever discussio=
ns which I have to confess that have not been actively following.



Best regards

Sergio


On 29/10/2014 16:14, Roni Even wrote:



Hi,

In the application token proposal we were trying to address two FEC issues:=




1. You assume that the SDP layer will know the SSRCs of the streams when ma=
king an offer. This may be true for point to point call but there are topol=
ogies (https://tools.ietf.org/html/draft-=
ietf-avtcore-rtp-topologies-update-04) where the SSRCs may not b=
e known to a Mixer who projects incoming RTP streams as is. This was the re=
ason for the application token. (this is a general issue with other use cas=
es when using SSRC in SDP and bundle tried to address part of it for identi=
fying the received RTP streams using the SDP group mid values)



2. For this case instead of using ssrc-group we proposed appId-group and de=
fine the mapping between an appId and the pt number to help identify the re=
lation in the SDP between the FEC streams and the source streams.





We had the feeling that the using the SSRC in SDP was causing multiple issu=
es and by using a token that does not have an RTP layer semantics we can ha=
ve a cleaner solution.





Roni





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

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia

Murillo

Sent: 29 October, 2014 2:30 PM

To: rtcweb@ietf.org

Subject: Re: [rtcweb] SDP and ssrc-group,



=C2=A0 From a formal perspective, I don't feel it is correct to describ=
e the semantical

meaning of an ssrc by referring to a payload.



Best regards

Sergio

On 29/10/2014 8:48, Roni Even wrote:



Hi,

We discussed this mapping issue in a previous version of the application to=
ken



draft http://tools.ietf.org/html/draft-even-mmu=
sic-application-token-02

example in section 1.



We thought of having a mapping from appId to "pt" (section 3.3.1)=
 Roni





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

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of I?aki Baz

Castillo

Sent: 21 October, 2014 7:26 PM

To: rtcweb@ietf.org

Subject: [rtcweb] SDP and ssrc-group,



Hi,



May I know which SSRC (345259865 or 2693756249) will be used for the

real media stream (plus RED and FEC) and which SSRC will be used for RTX?






--------------------------

m=3Dvideo 62164 RTP/SAVPF 100 116 117 96 a=3Dmid:video

a=3Drtpmap:100 VP8/90000

a=3Drtpmap:116 red/90000

a=3Drtpmap:117 ulpfec/90000

a=3Drtpmap:96 rtx/90000

a=3Dfmtp:96 apt=3D100

a=3Dssrc-group:FID 345259865 2693756249

a=3Dssrc:345259865 cname:erS7E/KHLYKTejNs

a=3Dssrc:345259865 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5<=
br>
c0134f05-e7c2-4afd-a979-4e224de5eb91

a=3Dssrc:345259865 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqB=
Y5

a=3Dssrc:345259865 label:c0134f05-e7c2-4afd-a979-4e224de5eb91

a=3Dssrc:2693756249 cname:erS7E/KHLYKTejNs

a=3Dssrc:2693756249 msid:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5
c0134f05-e7c2-4afd-a979-4e224de5eb91

a=3Dssrc:2693756249 mslabel:DWpWct9bWKzTMNYZn5bKVgwZ8Mfy2EtfqBY5=


a=3Dssrc:2693756249 label:c0134f05-e7c2-4afd-a979-4e224de5eb91

-------------------------------









RFC 5576 does not clarify it at all:



http://tools.ietf.org/html/rfc5576#section-4.2



--------------------------------------------------

4.2.=C2=A0 The "ssrc-group" Media Attribute



=C2=A0 =C2=A0 =C2=A0a=3Dssrc-group:<semantics> <ssrc-id> ...


=C2=A0 =C2=A0 =C2=A0[..]



=C2=A0 =C2=A0 =C2=A0The <semantics> parameter is taken from the speci=
fication of the

=C2=A0 =C2=A0 =C2=A0"group" attribute [RFC3388].=C2=A0 The initia=
l semantic values defined for

=C2=A0 =C2=A0 =C2=A0the "ssrc-group" attribute are FID (Flow Iden=
tification) [RFC3388]

=C2=A0 =C2=A0 =C2=A0and FEC (Forward Error Correction) [RFC4756].=C2=A0 In =
each case, the

=C2=A0 =C2=A0 =C2=A0relationship among the grouped sources is the same as t=
he

=C2=A0 =C2=A0 =C2=A0relationship among corresponding sources in media strea=
ms grouped

=C2=A0 =C2=A0 =C2=A0using the SDP "group" attribute.

--------------------------------------------------







The referenced RFC 3388 neither clarifies it:



---------------------------------------------------

7.4 FID Semantics



=C2=A0 =C2=A0 =C2=A0Several "m" lines grouped together using FID =
semantics form a media

=C2=A0 =C2=A0 =C2=A0flow.=C2=A0 A media agent handling a media flow that co=
mprises several "m"

=C2=A0 =C2=A0 =C2=A0lines MUST send a copy of the media to every "m&qu=
ot; line part of the

=C2=A0 =C2=A0 =C2=A0flow as long as the codecs and the direction attribute =
present in a

=C2=A0 =C2=A0 =C2=A0particular "m" line allow it.



=C2=A0 =C2=A0 =C2=A0It is assumed that the application uses only one codec =
at a time to

=C2=A0 =C2=A0 =C2=A0encode the media produced.=C2=A0 This codec MAY change =
dynamically during

=C2=A0 =C2=A0 =C2=A0the session, but at any particular moment only one code=
c is in use.



=C2=A0 =C2=A0 =C2=A0The application encodes the media using the current cod=
ec and checks

=C2=A0 =C2=A0 =C2=A0one by one all the "m" lines that are part of=
 the flow.=C2=A0 If a

=C2=A0 =C2=A0 =C2=A0particular "m" line contains the codec being =
used and the direction

=C2=A0 =C2=A0 =C2=A0attribute is "sendonly" or "sendrecv&quo=
t;, a copy of the encoded media is

=C2=A0 =C2=A0 =C2=A0sent to the address/port specified in that particular m=
edia stream.

=C2=A0 =C2=A0 =C2=A0If either the "m" line does not contain the c=
odec being used or the

=C2=A0 =C2=A0 =C2=A0direction attribute is neither "sendonly" nor=
 "sendrecv", nothing is

=C2=A0 =C2=A0 =C2=A0sent over this media stream.

----------------------------------------------------









So, how is the usage of ssrc-group? Where is it really defined?



Can I put more than 2 ssrc together in the same ssrc-group line?



How should the receiver interpret it?



Does a ssrc-group always mean RTX usage? Where is that specified in the

above SDP?



Does not the above SDP look a complete mixture of hacks and workarounds?








-





_______________________________________________

rtcweb mailing list

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





--089e015389eeaaa3ae050694dbb6--


From nobody Wed Oct 29 13:17:21 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5864A1A88AF for ; Wed, 29 Oct 2014 13:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvuC1EjFq-o8 for ; Wed, 29 Oct 2014 13:17:15 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4D21A88A0 for ; Wed, 29 Oct 2014 13:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11241; q=dns/txt; s=iport; t=1414613835; x=1415823435; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HOCFNxqtetu/ObKsumWqfohSKLOjUdd953xYueDc984=; b=GqLwSHiPH7owUMMYufR2BeAXWMNGZTXKeGWtQKJGKU2g/bCNQBX20GqZ g7Jo/TOKN1L4t3/kEG2DgwogaxqHZicRKUeKLN9HkJXigAOqDoG0np8Nw e18QC5bpvp1aJpeeKO+UfHRsqXrrCa4nE8/IJSZvT0i7t6Rsj+dEBRko2 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAJhKUVStJA2K/2dsb2JhbABcgkhGVFgEziGHTQKBHhYBAQEBAX2EAwEBBG4LEAIBCD8HMhQDAQ0CBAoEBQmIOA3IGwEBAQEBBQEBAQEBAQEBGpA/AQEkKweESwWPboIfhw2EUIExg0qRRYF+IIFabAGBDjmBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,279,1413244800";  d="scan'208,217";a="367622053"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 29 Oct 2014 20:17:14 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9TKHEni031252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 20:17:14 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 15:17:14 -0500
From: "Mo Zanaty (mzanaty)" 
To: Michael Tuexen 
Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving
Thread-Index: AQHP87VUDgEmq3WmIEG5yyqzWfrt0A==
Date: Wed, 29 Oct 2014 20:17:14 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se>  <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> <8CA6F4DE-8978-458B-9C77-21CFA33C48CE@lurchi.franken.de>
In-Reply-To: <8CA6F4DE-8978-458B-9C77-21CFA33C48CE@lurchi.franken.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [10.81.3.26]
Content-Type: multipart/alternative; boundary="_000_D076BBBF3D478mzanatyciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QwSrliZBJhDrpKksw-2jj5aexAs
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Oct 2014 20:17:18 -0000

--_000_D076BBBF3D478mzanatyciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Michael,
I moved to tsvwg as requested. See my reply to Karen, and one reply inline.
http://www.ietf.org/mail-archive/web/tsvwg/current/msg12899.html

For rtcweb, the main point is this. Will rtcweb apps care about blocking on=
 potentially fragmented messages? I think they definitely will, if they car=
e about blocking at all. Even simple JSON objects, which seem like natural =
message payloads, can easily exceed common MTUs. It doesn=92t take huge fil=
e transfers to require fragmentation.

Cheers,
Mo

On 10/29/14, 6:05 AM, Michael Tuexen > wrote:
On 28 Oct 2014, at 23:28, Mo Zanaty (mzanaty) > wrote:
On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" > wrote:
On 28 Oct 2014, at 21:52, Mo Zanaty (mzanaty) > wrote:
What resource is being conserved by not just requiring it?
8 bytes per packet (for MID+FSN).
Michael, the current NDATA draft requires it to be used for all messages if=
 negotiated. Can=92t this be relaxed / optimized to use it for all *fragmen=
ted* messages but use DATA for non-fragmented messages to avoid the 8 byte =
overhead for small messages (like game telemetry/control, an often cited us=
e of data channels).
You can bring this up at the tsvwg mailing list.
Mo: Will do.
However, we normally do not optimize for byte saving... Mixing
both makes the processing harder... Maybe we can use a bit in the flags to =
indicate if the additional fields are
there...
Mo: Type should already be enough without flags.
The current NDATA draft also says you can=92t interleave fragmented message=
s in a stream, so head of line blocking remains for all fragmented messages=
, while only small non-fragmented messages can avoid it. This dilutes the u=
tility of NDATA, perhaps enough to make apps that really care about head of=
 line blocking to implement their own app layer fragmentation with messages=
 well below common MTUs, hence defeating NDATA. Can=92t this also be relaxe=
d since MID is part of the NDATA extra header?
This would only make sense for messages marked as unordered... For ordered =
it doesn't make sense.
Mo: The restriction applies to unordered as well as ordered. Even for order=
ed, it does make sense to avoid head of line blocking at the sender.
I don't understand how you can do it for ordered. The sender sends a large =
message on stream 0 and after that
a small on stream zero. For both ordered delivery is request. So the receiv=
er can't deliver the second before the
first.

Mo: Blocking sender transmission is very different from blocking receiver d=
elivery to the app. It is wrong to assume all ordered protocols should bloc=
k sender transmission out of order. Windows and SACK improve performance of=
 ordered protocols despite the receiver blocking delivery to the app.

If those two issues are resolved, I see no argument against making NDATA a =
MUST in data channels.
Please let us discuss NDATA issues on the tsvwg mailing list...
Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its benefits=
 outweigh its costs. The current draft does not pass that bar for me. If my=
 app cares about HOL blocking, NDATA is not very useful, so my app must int=
ernally fragment, hence NDATA actually becomes harmful (8 bytes closer to e=
xceeding MTU, forcing SCTP fragments and hence risking HOL blocking).
I don't understand the point when I look at the API for data channels... On=
ly for sending messages
on a data channel not requiring ordered delivery. However, the intention of=
 NDATA is to mitigate
the impact of one data channel on others belonging to the same peer connect=
ion. This goal is met.
Best regards
Michael
Best regards
Michael
Mo
PS. Some believe data channels will be more widely used than WebRTC media (=
webtorrent, etc.), so it does make sense to consider the desirable properti=
es of a general peer-to-peer transport, and drop the WebRTC prefix when tal=
king about data channels.



--_000_D076BBBF3D478mzanatyciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <7DEBD6FE4B13F348B2A7DBF5189E57FB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi Michael,


I moved to tsvwg as requested. See my reply to Karen, and one reply in=
line.








For rtcweb, the main point is this. Will rtcweb apps care about blocki=
ng on potentially fragmented messages? I think they definitely will, if the=
y care about blocking at all. Even simple JSON objects, which seem like nat=
ural message payloads, can easily
 exceed common MTUs. It doesn=92t take huge file transfers to require fragm=
entation.







Cheers,


Mo







On 10/29/14, 6:05 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

On 28 Oct 2014, at 23:28, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:




On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de<=
/a>> wrote:











What resource is being conserved by not just requiring it?






8 bytes per packet (for MID+FSN).




Michael, the current NDATA draft requires it to be used for all messag=
es if negotiated. Can=92t this be relaxed / optimized to use it for all *fr=
agmented* messages but use DATA for non-fragmented messages to avoid the 8 =
byte overhead for small messages (like
 game telemetry/control, an often cited use of data channels).




You can bring this up at the tsvwg mailing list.




Mo: Will do.




However, we normally do not optimize for byte saving... Mixing


both makes the processing harder... Maybe we can use a bit in the flag=
s to indicate if the additional fields are


there...




Mo: Type should already be enough without flags.








The current NDATA draft also says you can=92t interleave fragmented me=
ssages in a stream, so head of line blocking remains for all fragmented mes=
sages, while only small non-fragmented messages can avoid it. This dilutes =
the utility of NDATA, perhaps enough
 to make apps that really care about head of line blocking to implement the=
ir own app layer fragmentation with messages well below common MTUs, hence =
defeating NDATA. Can=92t this also be relaxed since MID is part of the NDAT=
A extra header?




This would only make sense for messages marked as unordered... For ord=
ered it doesn't make sense.




Mo: The restriction applies to unordered as well as ordered. Even for =
ordered, it does make sense to avoid head of line blocking at the sender.





I don't understand how you can do it for ordered. The sender sends a l=
arge message on stream 0 and after that


a small on stream zero. For both ordered delivery is request. So the r=
eceiver can't deliver the second before the


first.







Mo: Blocking sender transmission is very different from blocking recei=
ver delivery to the app. It is wrong to assume all ordered protocols should=
 block sender transmission out of order. Windows and SACK improve performan=
ce of ordered protocols despite
 the receiver blocking delivery to the app.


 








If those two issues are resolved, I see no argument against making NDA=
TA a MUST in data channels.




Please let us discuss NDATA issues on the tsvwg mailing list...




Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its ben=
efits outweigh its costs. The current draft does not pass that bar for me. =
If my app cares about HOL blocking, NDATA is not very useful, so my app mus=
t internally fragment, hence NDATA
 actually becomes harmful (8 bytes closer to exceeding MTU, forcing SCTP fr=
agments and hence risking HOL blocking).




I don't understand the point when I look at the API for data channels.=
.. Only for sending messages


on a data channel not requiring ordered delivery. However, the intenti=
on of NDATA is to mitigate


the impact of one data channel on others belonging to the same peer co=
nnection. This goal is met.


Best regards


Michael






Best regards


Michael






Mo




PS. Some believe data channels will be more widely used than WebRTC me=
dia (webtorrent, etc.), so it does make sense to consider the desirable pro=
perties of a general peer-to-peer transport, and drop the WebRTC prefix whe=
n talking about data channels.






















--_000_D076BBBF3D478mzanatyciscocom_--


From nobody Thu Oct 30 11:54:53 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD841A1A8E for ; Thu, 30 Oct 2014 11:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level: 
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXWmqtm0lsxJ for ; Thu, 30 Oct 2014 11:54:50 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B4E1A1A1D for ; Thu, 30 Oct 2014 11:54:01 -0700 (PDT)
Received: from [192.168.1.200] (p508F2A72.dip0.t-ipconnect.de [80.143.42.114]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 47D171C104D94; Thu, 30 Oct 2014 19:53:58 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen 
In-Reply-To: 
Date: Thu, 30 Oct 2014 19:53:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5176B6FC-4F58-4299-8953-4E7AE4C29542@lurchi.franken.de>
References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se>  <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> <8CA6F4DE-8978-458B-9C77-21CFA33C48CE@lurchi.franken. de> 
To: "Mo Zanaty (mzanaty)" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q8kctHGqjjCE9mz7fYnNNP4gXWg
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Oct 2014 18:54:53 -0000

On 29 Oct 2014, at 21:17, Mo Zanaty (mzanaty)  wrote:

> Hi Michael,
> I moved to tsvwg as requested. See my reply to Karen, and one reply =
inline.
> http://www.ietf.org/mail-archive/web/tsvwg/current/msg12899.html
Great, thanks. I'll respond, but I'm really slow right now, since my day =
job
needs more time than I would like...
>=20
> For rtcweb, the main point is this. Will rtcweb apps care about =
blocking on potentially fragmented messages? I think they definitely =
will, if they care about blocking at all. Even simple JSON objects, =
which seem like natural message payloads, can easily exceed common MTUs. =
It doesn=92t take huge file transfers to require fragmentation.
Can you be a bit more specific? My understanding is:
1. Messages sent on one data channel should not block messages sent on a =
different channel.
   I hope we agree on this and this goal can be reached with N-DATA.
2. If you send a larger message on an ordered data channel, it will =
block other
   messages sent on the same data channel. Since it is an ordered =
channel, this can't
   be avoided. I hope we also agree on this.
3. If you send a large message on an unordered data channel, and a small =
one after
   that, there is no statement made in which these messages would be =
delivered.
   Are you focussing on this and do you want to require some sort of =
reordering?

Best regards
Michael
>=20
> Cheers,
> Mo
>=20
> On 10/29/14, 6:05 AM, Michael Tuexen =
 wrote:
> On 28 Oct 2014, at 23:28, Mo Zanaty (mzanaty)  =
wrote:
>> On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" =
 wrote:
>> On 28 Oct 2014, at 21:52, Mo Zanaty (mzanaty)  =
wrote:
>>>> What resource is being conserved by not just requiring it?
>>> 8 bytes per packet (for MID+FSN).
>>> Michael, the current NDATA draft requires it to be used for all =
messages if negotiated. Can=92t this be relaxed / optimized to use it =
for all *fragmented* messages but use DATA for non-fragmented messages =
to avoid the 8 byte overhead for small messages (like game =
telemetry/control, an often cited use of data channels).
>> You can bring this up at the tsvwg mailing list.
>> Mo: Will do.
>> However, we normally do not optimize for byte saving... Mixing
>> both makes the processing harder... Maybe we can use a bit in the =
flags to indicate if the additional fields are
>> there...
>> Mo: Type should already be enough without flags.
>>> The current NDATA draft also says you can=92t interleave fragmented =
messages in a stream, so head of line blocking remains for all =
fragmented messages, while only small non-fragmented messages can avoid =
it. This dilutes the utility of NDATA, perhaps enough to make apps that =
really care about head of line blocking to implement their own app layer =
fragmentation with messages well below common MTUs, hence defeating =
NDATA. Can=92t this also be relaxed since MID is part of the NDATA extra =
header?
>> This would only make sense for messages marked as unordered... For =
ordered it doesn't make sense.
>> Mo: The restriction applies to unordered as well as ordered. Even for =
ordered, it does make sense to avoid head of line blocking at the =
sender.
> I don't understand how you can do it for ordered. The sender sends a =
large message on stream 0 and after that
> a small on stream zero. For both ordered delivery is request. So the =
receiver can't deliver the second before the
> first.
>=20
> Mo: Blocking sender transmission is very different from blocking =
receiver delivery to the app. It is wrong to assume all ordered =
protocols should block sender transmission out of order. Windows and =
SACK improve performance of ordered protocols despite the receiver =
blocking delivery to the app.
> =20
>>> If those two issues are resolved, I see no argument against making =
NDATA a MUST in data channels.
>> Please let us discuss NDATA issues on the tsvwg mailing list...
>> Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its =
benefits outweigh its costs. The current draft does not pass that bar =
for me. If my app cares about HOL blocking, NDATA is not very useful, so =
my app must internally fragment, hence NDATA actually becomes harmful (8 =
bytes closer to exceeding MTU, forcing SCTP fragments and hence risking =
HOL blocking).
> I don't understand the point when I look at the API for data =
channels... Only for sending messages
> on a data channel not requiring ordered delivery. However, the =
intention of NDATA is to mitigate
> the impact of one data channel on others belonging to the same peer =
connection. This goal is met.
> Best regards
> Michael
>> Best regards
>> Michael
>>> Mo
>>> PS. Some believe data channels will be more widely used than WebRTC =
media (webtorrent, etc.), so it does make sense to consider the =
desirable properties of a general peer-to-peer transport, and drop the =
WebRTC prefix when talking about data channels.
>=20
>=20


From nobody Thu Oct 30 14:56:02 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786751A8855 for ; Thu, 30 Oct 2014 14:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level: 
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8LP2Qe5uZl1 for ; Thu, 30 Oct 2014 14:55:57 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4881A8843 for ; Thu, 30 Oct 2014 14:55:57 -0700 (PDT)
Received: from [192.168.1.200] (p508F2F98.dip0.t-ipconnect.de [80.143.47.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 450D11C0ACE41; Thu, 30 Oct 2014 22:55:54 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen 
In-Reply-To: 
Date: Thu, 30 Oct 2014 22:55:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DFFB0BA-078A-44BC-BE78-E31077A2174C@lurchi.franken.de>
References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se>  <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> <8CA6F4DE-8978-458B-9C77-21CFA33C48CE@lurchi.franken. de> 
To: "Mo Zanaty (mzanaty)" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Cp75DY7r7ovgT0sCVlCwFgOFGCY
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Oct 2014 21:56:00 -0000

On 29 Oct 2014, at 21:17, Mo Zanaty (mzanaty)  wrote:

> Hi Michael,
> I moved to tsvwg as requested. See my reply to Karen, and one reply =
inline.
> http://www.ietf.org/mail-archive/web/tsvwg/current/msg12899.html
>=20
> For rtcweb, the main point is this. Will rtcweb apps care about =
blocking on potentially fragmented messages? I think they definitely =
will, if they care about blocking at all. Even simple JSON objects, =
which seem like natural message payloads, can easily exceed common MTUs. =
It doesn=92t take huge file transfers to require fragmentation.
After thinking about it a bit more:

Assume an unordered data channel dc and the application calls
dc.send(big_msg);
dc.send(small_msg);
How do you decide whether the intended behaviour is either
(a) deliver big_msg before small_msg
(b) deliver small_msg before big_msg
I don't see any way in the W3C API to indicate this. Both alternative
might the appropriate in different scenarios.

Best regards
Michael
>=20
> Cheers,
> Mo
>=20
> On 10/29/14, 6:05 AM, Michael Tuexen =
 wrote:
> On 28 Oct 2014, at 23:28, Mo Zanaty (mzanaty)  =
wrote:
>> On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" =
 wrote:
>> On 28 Oct 2014, at 21:52, Mo Zanaty (mzanaty)  =
wrote:
>>>> What resource is being conserved by not just requiring it?
>>> 8 bytes per packet (for MID+FSN).
>>> Michael, the current NDATA draft requires it to be used for all =
messages if negotiated. Can=92t this be relaxed / optimized to use it =
for all *fragmented* messages but use DATA for non-fragmented messages =
to avoid the 8 byte overhead for small messages (like game =
telemetry/control, an often cited use of data channels).
>> You can bring this up at the tsvwg mailing list.
>> Mo: Will do.
>> However, we normally do not optimize for byte saving... Mixing
>> both makes the processing harder... Maybe we can use a bit in the =
flags to indicate if the additional fields are
>> there...
>> Mo: Type should already be enough without flags.
>>> The current NDATA draft also says you can=92t interleave fragmented =
messages in a stream, so head of line blocking remains for all =
fragmented messages, while only small non-fragmented messages can avoid =
it. This dilutes the utility of NDATA, perhaps enough to make apps that =
really care about head of line blocking to implement their own app layer =
fragmentation with messages well below common MTUs, hence defeating =
NDATA. Can=92t this also be relaxed since MID is part of the NDATA extra =
header?
>> This would only make sense for messages marked as unordered... For =
ordered it doesn't make sense.
>> Mo: The restriction applies to unordered as well as ordered. Even for =
ordered, it does make sense to avoid head of line blocking at the =
sender.
> I don't understand how you can do it for ordered. The sender sends a =
large message on stream 0 and after that
> a small on stream zero. For both ordered delivery is request. So the =
receiver can't deliver the second before the
> first.
>=20
> Mo: Blocking sender transmission is very different from blocking =
receiver delivery to the app. It is wrong to assume all ordered =
protocols should block sender transmission out of order. Windows and =
SACK improve performance of ordered protocols despite the receiver =
blocking delivery to the app.
> =20
>>> If those two issues are resolved, I see no argument against making =
NDATA a MUST in data channels.
>> Please let us discuss NDATA issues on the tsvwg mailing list...
>> Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its =
benefits outweigh its costs. The current draft does not pass that bar =
for me. If my app cares about HOL blocking, NDATA is not very useful, so =
my app must internally fragment, hence NDATA actually becomes harmful (8 =
bytes closer to exceeding MTU, forcing SCTP fragments and hence risking =
HOL blocking).
> I don't understand the point when I look at the API for data =
channels... Only for sending messages
> on a data channel not requiring ordered delivery. However, the =
intention of NDATA is to mitigate
> the impact of one data channel on others belonging to the same peer =
connection. This goal is met.
> Best regards
> Michael
>> Best regards
>> Michael
>>> Mo
>>> PS. Some believe data channels will be more widely used than WebRTC =
media (webtorrent, etc.), so it does make sense to consider the =
desirable properties of a general peer-to-peer transport, and drop the =
WebRTC prefix when talking about data channels.
>=20
>=20


From nobody Fri Oct 31 11:18:01 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796171A03A6 for ; Fri, 31 Oct 2014 11:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC4vddlBfERD for ; Fri, 31 Oct 2014 11:17:57 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F035E1A03A3 for ; Fri, 31 Oct 2014 11:17:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3255; q=dns/txt; s=iport; t=1414779476; x=1415989076; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GWEnnVFfoUIGCn9D8TbUdJvZGzE2lqu4Qln7s7AmadA=; b=LR//8KKv0qQxNOfRyS7hySI7MoRb8SJ80xFhpiLSGnNr8vgWiPzXXv9T f32eFhj6X6J4lpp3Yy6tz5H/yhU/p2Qz7JQTBaTZQ5eoPsIJ29KSI46il Ha2mAdYjzuDnwrI6jLN1qJxQaue1Gmbaogp6pqnZTqKsdaN0BvUnA2ir+ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah0FAP7QU1StJA2D/2dsb2JhbABcgw6BLATUdQKBGRYBAQEBAX2EAwEBBHkQAgEIRjIlAgQKBAUbiCbLJAEBAQEBAQEBAQEBAQEBAQEBAQEZkGUrB4RLBYszhEOCH4cQhFOBMZEOhAmDeGwBgUeBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="92209864"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 31 Oct 2014 18:17:56 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9VIHuad005191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 18:17:56 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.159]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 13:17:55 -0500
From: "Mo Zanaty (mzanaty)" 
To: Michael Tuexen 
Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving
Thread-Index: AQHP9Tb9flhRKPwK+0CahQGt2FaUYQ==
Date: Fri, 31 Oct 2014 18:17:55 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4CD241@ESESSMB209.ericsson.se> <544E8D92.8010401@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D4CE9DA@ESESSMB209.ericsson.se> <5B74C903-7C9A-4D74-B5CC-D0643A377935@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4CEBAB@ESESSMB209.ericsson.se> <9A1C16CE-1423-448B-943F-33B3068156F3@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D4D0CE8@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4D1044@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D4D14F7@ESESSMB209.ericsson.se>  <4704857B-ED34-4B3D-9CC6-A60801586F6B@lurchi.franken.de> <3904F698-8B45-44E9-9E43-81D53467E3A6@cisco.com> <8CA6F4DE-8978-458B-9C77-21CFA33C48CE@lurchi.franken.de>  <9DFFB0BA-078A-44BC-BE78-E31077A2174C@lurchi.franken.de>
In-Reply-To: <9DFFB0BA-078A-44BC-BE78-E31077A2174C@lurchi.franken.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [10.81.3.22]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <78E2E79CA77DBA479BD467993A584B3F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/p9BAgnfmCr9DUHLHFV46aGY9N94
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 31 Oct 2014 18:17:59 -0000

Hi Michael,
Merging your points and replying here since we are firmly in rtcweb cases.
We can summarize for tsvwg once concluded (if we reach any conclusion).

Consider real rtcweb apps that have many potentially large blobs to
transfer, like proxy browsing, webtorrent, chats with file exchange, games
with object exchange, etc. Developers may think sending these blobs as
messages on an unordered channel would work without HOL blocking. But they
would be wrong since the current NDATA spec actually blocks, effectively
behaving like an ordered channel.

Once they debug this, they will rewrite the app to either:
1) create a new channel for every blob, which is excessive overhead for
the app, browser and SCTP stack (but NDATA does at least enable this
solution), or
2) fragment blobs in the app, which adds (some but less) overhead for the
app (and defeats NDATA).

These are the only ways to get unordered, non-blocking delivery. At least
NDATA makes the app hack 1) possible since channels don=B9t block each
other. But it would be far more useful if unordered channels did not block
like ordered ones.

More inline.

Cheers,
Mo

On 10/30/14, 2:53 PM, Michael Tuexen 
wrote:
Can you be a bit more specific? My understanding is:
1. Messages sent on one data channel should not block messages sent on a
different channel.
   I hope we agree on this and this goal can be reached with N-DATA.
2. If you send a larger message on an ordered data channel, it will block
other
   messages sent on the same data channel. Since it is an ordered channel,
this can't
   be avoided. I hope we also agree on this.
3. If you send a large message on an unordered data channel, and a small
one after
   that, there is no statement made in which these messages would be
delivered.
   Are you focussing on this and do you want to require some sort of
reordering?

Mo: Agreed on 1 and 2, with the admittedly minor caveat mentioned earlier
on 2 about blocking sender transmission vs. receiver delivery to app. For
3, which is indeed my focus, agreed the W3C spec makes no statement about
order (since the channel is unordered!), but the NDATA spec actually does
mandate HOL order for messages>MTU, which is counter to the whole point of
an unordered channel. A developer must override defaults to get an
unordered channel, presumably to get faster, non-blocking delivery for the
individual messages. Otherwise, what is the point of unordered channels if
they block just like ordered ones?


On 10/30/14, 5:55 PM, Michael Tuexen 
wrote:
Assume an unordered data channel dc and the application calls
dc.send(big_msg);
dc.send(small_msg);
How do you decide whether the intended behaviour is either
(a) deliver big_msg before small_msg
(b) deliver small_msg before big_msg
I don't see any way in the W3C API to indicate this. Both alternative
might the appropriate in different scenarios.

Mo: The point of unordered channels is to send and receive everything
whenever it becomes available. The transport does not need to worry about
providing any specific ordering, but it is not expected to block based on
internal ordering rules.